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ABSTRACT 

Computer technology hat had limited success in producing useful business 

! PP i tea '?!!*- Ma "H emOT, LW*" 1 »«**?» «^ wm* roautanwn^are of ten inappropriate 
to»fra|iplic«ion f i^ ^ 

Business lacks expertise in the application of computers. Managers who are 

expert in solving borrne* problem* find ft mkOkrotp^irohHtiprt^u^ for the 

solution of these problems. It is not surprising that prpi r amm o u who work, from poorly 

defined spedftattom produce pU^wSMmW^Umi^ provided 

only limited support In business appbcaOoni. Appticattpn pedum are «jMom rppnwrlMf 

failure in practical situations. 

Improvements are certainly possible. The manager could be supplied with a 
system that assists in the design of an apokcaoon. This system could help the manager 
specify his requirements by providing him with a framework for thinking about issues 
relevant to the design of a particular application. The manager might then be better 
equipped to select a commercial package or to guide in the design of his own 
implementation. 

This thesis describes a prototype version of such a system. PROCTOR is a 
program that assists in the design of a hierarchical planning and control system for a 
procurement firm 

PROCTOR is implemented as an "unstructured" questionnaire, ft guides the 
user in investigating various aspects of a problem while giving him complete freedom in 
deciding how and when to supply answers to questions, ft allows Mm to change and skip 
answers whenever he desires. PROCTOR ii implemented in OWL. a system for 
r eprese nting and processing conceptual knowledge It uses the OWL data base to represent 
procedures for the questionnaire and to store data scomulated during the interaction. This 
representation makes possible the presentation of an English-tike problem description, 
various evaluations and the reasons for the evaluations. 

Thesis Supervisor: William A Martin 

Title: Associate Professor of Electrical Engineering and Management 
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CHAPTER 1 
INTRODUCTION AND BACKGROUND 

U Introduction 

Computer technology hat had limited success in producing useful business 
applications. Management systems seldom meet the users' requirements, are often 
inappropriate to an application, and are frequently abandoned. But why? 

Business lacks expertise in the application of computers. Managers who are 
expert in business problems find it difficult to specify formal procedures for the solution of 
these problems. It is not surprising that programmers who work from poorly defined 
specifications produce poorly written application software. 

The computer industry has provided only limited support in business 
applications. Application packages should theoretically provide instant data processing 
software In practise, they require considerable modification to be compatible with a firm's 
procedures. Application customiiers are proposed as a solution to this problem. These 
systems tailor application packages from user specifications. Unfortunately, outputs from 
application customlzers still require modification to f it the environment of a firm. 

Application customlzers (and application packages) have a more serious 
limitation: a user is rarely provided with evaluations concerning the suitability of a package 
for his firm. A company will invest considerable time and expense in "ready to run" 
software only to discover that it is inapplicable to its problem. And worse, the unsuitable 
package can sometimes aggravate a company's problems. 

Improvements are certainly possible. The manager could be supplied with a 



system that assists in the design of an application. This system could help the manager 
specify his requirements by providing him with a framework for thinking about issues 
relevant to the design of a particular application. The manager might then be better 
equipped to select a commercial package or to guide in the design of his own 
implementation. 

This thesis describes a prototype version of such a system PROCTOR is a 
program that guides the user in the design of a system for a particular application. The 
application U assumed to be a planning and control system for a procurement firm designed 
according to the aggregation methodology of hierarchical planning and control described ty 
HaxandMeaL <Hax and Meil 76> ; '*'"' : ""* "' •"""^**" w '-' 

PROCTOR is based on a quettkmnairt written by Professor Arnoldo C. Hax. 
This questionnaire served as a summary of issues to be considered in the design of a 
hierarchical planning and control system for procurement The questionnaire served as a 
baste for an analysis that in turn influenced the implementation of PROCTOR. 

PROCTOR is implemented as a "umtructured" mukipte choice qu«fUonnalre. It 
guides the user in investigating a problem while giving htm complete freedom in deckling 
how and when to supply answers to questions. PROCTOR allows the user to change and 
skip answers whenever he desires. 

We have implemented PROCTOR in OWL, a system for representing and 
processing conceptual knowledge <Hawkinson 7S> PROCTOR uses the OWL data base to 
represent the procedures for the questionnaire and to store data accumulated during the 
interaction. The data base makes possible the presentation of an EngUsh-Uke summary of 
the problem setting as well as rtc o min e nd aUons concerning > possible syttem for the problem. 



L2 Background 

I.2J Application Customize!-* 

In the introduction, we mentioned that iipera of application customixer* 
frequently encounter problem*. IBM'i Application C*i»tomiwr <IBM 72> and tht 
Distributions System Simulator <Connor» 72> are typical tx*ropl« pf application cuttomizen. 

The Application Cuitomizer to a sysftm that um a qiiestionnaire to derive a tat 
of parameters that are subsequently uaed to cuttoroise data pro c essi n g aaf tware. The most 
serious limitation of the Application Cusgomizer it that it don littk in terms of problem 
formulation. <Ha* and Martin 7J> The Application Customiier cannot evaluate the 
applicability of its output for a particular situation. In uiinf the AppUcatlon Customlzer, 
the user bears full responsibility for identifying hto processing requiremenu and for 
determining if the resulting system to indeed appropriate to his problem. 

The Distribution Systems Simulator (DSS) is a system that uses a questionnaire 
to customize a simulation model for large scale physical distribution systems. DSS offers an 
improvement over the Application Cuitomizer by providing a means of evaluating 
distribution systems methodology. But it also to Inadequate <Hax 74b>. DSS does not take a 
global view of the firm in its evaluations. It ignores important issues such as the interaction 
of the firm's production activities with the distribution process: it treats manufacturing 
planu as sources of unlimited inventory. DSS does not provide an Integrated approach in 
the logistics process: it treats each stocking point as If it were independent from the rest of 
the system. 
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1.2.2 Requirenients for an Improved System 

The minimum requirements for an improved system ihouW be dWrV A system 
that is to provide an improvement over existing systems ihouM assist the user in (1) 
identifying his requirements, (2) selecting component! to meet his reouiremente, and in <$) 
evaluating the suitability of these components for hU situation. In meeting these objectives, 
the system mint take ft global view of the firm. 

PROCTOR tries to meet these objectivei by means of an Interactive multiple 
choice questionnaire. We chose this approach for several reasons. It has proven successful 
in both the Application Customizer and the Distribution* System Simulator and seemed to be 
the simpteit technology which could support ah advance over existing systems. A 
questionnaire requires a minimum of input and is therefore readily accepted by management 
A questionnaire provides a framework in which it to possible to educate a user: it can guide 
the non-expert in the description of ht» problem. 

We have made several improv e me n ts in the presentation of the questionnaire. It 
is often the case that the user cannot continue in a questionnaire because he does not know 
an answer or because he doss not know how to answer a question. Many systems are unable 
to proceed unless an answer to suppled, {& il poor software engineering to force the user to 
have a long involved interaction in order to determine a single piece of information.) 
PROCTOR allows the user to skip a question whenever he desires. It then tries to 
determine the fact by tiling information that it already knows or by using a different 
strategy in asking for information. PROCTOR can also proceed to another part of the 
investigation. The user can Interrupt PROCTOR at any time to supply answers to questions 
that have been skipped. 
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Associated with the ability to skip answers Js the ability to change answers 
whenever the user desires. The user may wish to change a previous answer: the program 
may have detected the inconsistency of a response with previous information; the user's 
supervisor may disagree with information that hu suppuol PROCTOR U able to change 
answers without having to restart the investigation. 

A deficiency with application i customtiers U their InablHty to provide evaluations 
before the completion of the auestiorautire. The Application CuatornUer questionnaire roust 
be completed before any output to available. PROCTOR can provide partial evaluations 
bef on a session is completed. 

1.2.3 Methodology for Research 

L25J A Consultant's Questionnaire as Protocol 

PROCTOR is based on a questionnaire written by Prof essor Arnoldp C Hax. 
Professor Hax has discussed the need for programs capable of automating the design of 
logistics systems <Hax 74c>. As an attempt toward* such a system, he wrote in a 
questionnaire format his strategy for tickling procurement problemi 

The questionnaire served as a summary of issues that had t» be considered 
when attempting the design of a hierarchical pfenning and control system for procurement 
An analysis of the questionnaire lead to a theory of to structure that in turn Influenced the 
implementation of PROCTOR. This will be dtocussed in a later chanter. Jt suffices to note 
that several assumptions had to be made hi the writing of the questionnaire and its 
subsequent analysis. 
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L2.3.2 Some Necessary Assumptions 

The questionnaire only considers operational and tactical Issues. It contains no 
questions concerning long term strategic considerations such as those Involved in the design 
of plants and warehouses or the allocation of capital. Although tils Is a reasonable 
restriction, it can lead to complications. The consultant is often confronted by a situation 
that on the surface seems to be a procurement problem. On further investigation, the real 
problem Is often found to be quite different: the fhni's f adttties could be constrained and 
require expansion; funds for Inventory investment might not be available due to limited 
cash flows that arise because of the firm's credit poticr. 

We assume that before using the program, the user will have analyzed his 
situation to the extent that he is convinced that a purchasing or inventory problem requiring 
a procurement system exists. Thus, the questionnaire tackles only operational and tactical 
Issues without regard to strategic, long term issues that aire assumed to be externally 
constrained. 

Another problem is the evaluation of the numerous intangibles involved in 
deciding whether or not to use a particular logistics system. It is inconceivable given the 
current state of the art that a program be able to decide many situation whether a planning 
and control system ihouW be adopted. i?ot a general analysis, a program would require a set 
of wen-developed world models to enable it to relate to the many secondary issues involved. 
A manager is needed to evaluate intangibles such as organizational issues and financial 
considerations related to an overall decision. 
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L8 Operations Manage went Issues 

In thU section, we outline the kinds of procurement problems that PROCTOR 
considers. We also describe the hierarchical approach to planning and control systems 
described by Hax and Meal 



LSJ The Procurement Problem Outlined 

Procurement refers to the ongoing activity that all firms have of purchasing 
materials and supplies from outside sources. A manufacturing firm will purchase raw 
materials to supply its production process. For a distributor (such as a supermarket chain), 
procurement depends on the requirement* of the individual stoct^ potatt. Many firms 
(retailers and wholesalers, for example) purchase goods simply to satisfy the demands of 



their customers. 

In this thesis, we consider those firms whose major activity is procurement. In 

this class, we include not only simple retailers *«^ W« ^J»™ .?^ P redllCtto,, 
activities with ncgngible production lead times (such as packagers) and firms which have 
distribution activities that can be assumed to be independent of the procurement process. 

Support for the procurement process depends on the time horizon in which we 
hope to provide support. For a horizon of more than a year, long-term issues such as the 
acquisition of plant and equipment assets and factttttas design become important Product 
tine selection may also be considered. For a very short horizon of a few days to less than a 
month, issues related to the detailed scheduling of company operations become important. 
For a medium horizon of less than a month to a year, we become concerned with the 
forecasting of customer demand, the planning of inventory levels and the purchasing of 
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goods. This thesis considers issues of planning and control in the medium time horizon. 

Within this time horizon, the firm's objective is to provide good customer 
service at minimal cost without violating constraints that are imposed either externally or 
internally to the company. Unfortunately, a firm can meet many problems in trying to meet 
this objective 

A company that cannot adequately forecast customer demand will suffer a 
deterioration of customer service and subsequent lees of business. In addition, it will often 
accumulate excess inventory. This merely aggravates the situation by wasting valuable space 
that should be used to hold goods that are currently in demand. 

A firm that U unable to predict the lead nine between the issue and receipt of 
an order from a vendor wilt usually suffer mused customer orders ami lost sales. To solve 
this problem, a company will sometimes issue many small orders. The remit is excessive 
ordering costs. 

A firm's procurement problems an sometimes result from its inability to operate 
within the constraints imposed on it Vendors occasionally set supply limits and sometimes 
require constant purchasing rates. Occasionally, the finance department of the firm can 
Impose a constraint by limiting funds available for investment in inventory. 

All these problems warrant the consideration of a planning and control system. 
But a firm need not have procurement problems to consider such a system. Indeed, a firm 
may consider a system simply to maintain its competitive advantage. With a planning and 
control system, a firm will be better able to predict customer demand to take advantage of 
discounts and economies of transportation when ordering from vendors. Extra cash is made 
available to finance other aspects of the company's operations by keeping inventory 
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investment at a minimum. 

L12 The Hierarchical Approach to Planning and Control Systems 

There are several approaches to the design of a planning and control system for 
the procurement situation. One proposal is to formulate the control problem as a single 
mixed-integer programming problem (MIP) to be soWed on a rolhng horizon basis. <Lasdon 
and Terjung 71> 

Several researchers have discussed the deficiencies of this approach. (See, for 
example, <Bttran and Hax %>.) One problem with the data bach U that If requires 

data such as forecasted demand for each item over the planning horizon (usually a year). 
For several thousands of Hems, not only do data requirements become overwhelming but 
usually it becomes computationally impossible to obtain a solution to the MIP. Another 
objection to the detailed solution is that it provides no rneaiu for management intervention 
in the solution process. 

Hax and Meal and othenXsee <Hax aitd Meal 75> ai»d <Hiiusman and Heat 
60>) have recommended a hierarchical approach to planning «idjpttjr©|, In this thesis, . ; we 
assume the approach of Hax and Meal as the proposed owthodotogy for a planning and 
control system. 

The hierarchicaj approach requires that aggreta* decjijoni be made first, and 
that these be later used to constrain more detailed decision*. Esch level of decision making 
has its characteristic length of planning horizon and data requirements. More aggregate 
decisions involve longer horizons and less detaited kinds of information. With the 
hierarchical approach, ate manager is able to Influence the johiUon at each level of decision 



making. Typically, upptr management will influence the decisions at a higher level of 
aggregation. 

In designing a planning and control system, the types of aggregations required, 
the problem* to be solved at each level of aggregation and the linkage mechanism between 
levels must be selected. 

For medium range planning problems (a horizon of approximately a year), three 
levels of aggregation have been identified: 

Itms are final products to be delivered to the customers. They represent the 
highest d^r« of ipeciftcHy rtftrding th< product handkd by the firm. Item* differ 
in terms of characteristics such as colbr, packaging, kbets, accessories and size 

FamtiUi are groups of items whkh l share a common ordering cost Economies 
of scale are made pojsibfe by Jointly replenishing ttemi belonging to the same family. 

T JP* "f ■ J"*** of families whose procurement qn^ntitiej are to be determined 
by an aggregate plan (a linear programming model at the type level). Families 
belonging to a type normally have similar inventory characteristia and similar demand 
patterns. " ■■■'""'' " "" '" ' >,! '" " : " l '"' ; '*"" " ■'' '" v ■"-■'-■-;«• "■;■ 

These three levels of aggregation are used in COMS, a Computer Based 
Operations Management System. <Hax. Cokwih, Bbsy j and Vfctor J6V this system was 
designed as a research tool to explore various technique* i*br Iftking between the levels of 
aggregation. COMS has strongly Influent*! our model of a general hierarchical planning 
and control system. Figure U gives a conceptual overview of COMS. 

After updating last period's performance statistics, d*n*ndi are forecast both at 
the type and the item level. Th# type levet forecast is mad* over the planning horizon 
(usually a year j. The system aggregates data to the type IrVel to rmnimiie errors due to the 
uncertainty of future requirements at the item level. It is thus able to provide a more 
realistic forecast over the planning horizon. The Item level forecast is simply a forecast of 
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Read in last period's usage 



imtm^m^r^m^^ 



Update Inventory Status 
(Physical fiwfentory; Amount e# 
Order, Backorders, Lost Sales, 
AvaHablelnventorf) 



Update demand forecasts, safety 
stocks, overstock limits, and 
run out times 



for each product type 



Aggregate Plan for Types 
(Aggregate Planning Reports) 



Family Dfsa|fcr«gatforr 
(Family Planning Reports) 



Item Disaggregation 
(Itim Plann% Report) 



Detailed Statui Reports 



[emeni 
Interaction 
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Conceptual Overview of a Hierarchical Planning System 

Figure 1.1 
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next period's requirements bated on the part performance of tech item. 

After making theie forecasts, the system updates safety stocks, overstock limits 
and run out times. The safety stock u ttw tmnumun mventery, fevtl necessary to keep the 
probability of stock outs at a desired level It is cemputeoUuing the standard deviation of 
errors in the forecasts. Overstock limits are maximum inventory levels. They are important 
for items which have periods tfi^ssJe^ Jo these periods, $f iftJNft tries to keep inventory 
levels near sera The run out time is me time in .which m item wit run out if no order is 
placed. It depends on forecasted demands and inventory levels. 

The system solves a Hpteat program that use* u>e«e«Bu*meter» as well as type 
inventories and procurement lead tinm. The lolution U vscheduk for procurement over the 
coming horizon that minimiies com white oc^li^ certain constraint*. The most important 
cost is that for holding inventory. The constraints are ge constraints, seasonal 

constraints and supplier purchasing constraints, the system uses the first period in the 
solution to determine order am+unts m'me.coiM^p|^^ 

f ype procurement amounu are assigned .{disaggregated) to families in types. 
This is done by means of an algorithm that insures that aggregate demand for families U 
satisfied in the next period while total setup costt (ccett <tf ^ order) and holding 

costs are minimized. 

Once family amounu have been allocated, actual order amounts for items in 
families are assigned. To reap benefits of Joint economies of scale, items in a family should 
be ordered together. Item amounts are allocated so that family members run out 
simultaneously. 

The preceding description is that of a fairly general planning and control 
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system. In certain cases, only some of the components are applicable. The aggregate 
planning component may be eliminated when a firm has no long-term external constraints. 
Families are not present when items can only be ordered Individually from vendors. 

Th « tg* r *** tton approach has been tested for several problems using the 
COMS system. <Hax et al. 76> It is interesting to note that costs obtained using this 
approach are very near the tower bound cost* provided by the MI? formulation. In tome 
cases, COMS has been able to provide a feasible solution white the MIP has failed due to 
computer storage limitations. 

L4 Preview 

In the next chapter we present a sample session using PROCTOR. Chapter S 
contains a description of the questionnaire. In chapter 4, we develop a model of the 
questionnaire strategy. Chapter ft describes the Inytementation of this model 



CHAFTgR 2 
A SYSTEM DEMONSTRATION 

Chapter I introduced the procurement problm and the hierarchical approach to 
its solution. It also presented "a set of requirements for a system to assist the manager in 
evaluating the suitability oV thit approach for hii firm, ta this chapter, we describe a 
session Wittf the current implementabon of the system. We wm demonstrate PkOCT Ofc by 
outlining the experiences of a typical user. 

21 Introduction 

Adam Smith is manager of operations at KBS FoocU Limited, a noted wholesaler 
of specialty product! KBS purchases prepackaged foods, occasionally repackages them and 
salts them to gourmet shops and direct to the public For KBS 4 , repackaging is a minor 
activity that requires no lead time and little overhead: it simply involves relabelling items 
for certain shops. KBS Foods handles more than 5000 items. Demand for these items varies 
according to the season with peaks at holiday times. 

KBS is currently experiencing problems in its inventory management Items are 
often understocked; an item is occasionally unavailable due to monthly supply limits 
imposed by vendors; orders are often missed or shipped late. KBS has also overstocked 
some of its items. This has created a significant overhead in operating expenses since items 
that cannot be sold incur storage costs or have to be liquidated. 

Mr. Smith believes that computer control of the procurement operations of 
KBS Foods would be the most appropriate solution. He is especially interested in an 



approach that uses management science techniques. An associate ha* JMjpMA that ht use 
PROCTOR to help him decide. 

2.2 The Session 

In the following pages, we present segments of Mr. Smith's session with 
PROCTOR. The complete session appears in Appendix A. 

Mr. Swath has fust completed tnoesttgatums tnto support; for fafntordemitnieracttons. 
PROCTOR has conclude that fotnt ordering support ts foastok because KB* Foods has a 
stjruftcantmmlf*rofttmstk«tiMr$ mdemg tuti turf h ugafUVM Hems can be grouped 
tnto famtUes for purposes of feint rtpUntshment. PROCTOR uowbegm twe stt g etlo ns into 
external constraints. 

And Mr. Smith, we will now attempt to identtfy whetl»er there are external constrainu 
among your items that warrant the development of an aggregate ptoA and the Aggregation 
of items and families of items into product types. Do you need further information with 
regardi to external interaction*? 
(Please her in yes or no); res 

The presence of external constraints such m storage Umitattons, financial 
constraints, limited camefty of ^ttui\ytri<^y*^*ui»^im<to^^ 
under fluctuating requirements may fords die development of a purchasing plan during a 

""•J ame *^fcf*|! * W4. ^ *»* f«nfomf, ftp* a» tb« aggregated tnto 

product types ^to fadB** design and ^kmeomiOD of th pjje 

purchasing plan is required whenever purchasing decisions have to be made looking more 
than one purchasing lead time ahead, and items are c ompe tin g for scarce resources under 
fluctuating demand conditions. 

PROCTOR uses fuestton H through 21 to determine the existence of external constraints tn 
KBS Foods. An aggregate pinning module ts considered if atlenUoneeonstratntU present. 

(1?) Are there storage constraints that limit the amount of physical inventory you could 

handle? 

(Please key in yes or no): n 

(18) And Mr. Smith, are there financial constraints that force you to define a fairly constant 
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purchasing rale each month? 
(Please key in yes or no): n 

(19) Are there contracts you sign with Individual vendors which force you to define a fairly 
constant purchasing rate every month? 

(Please key in yes or no> ? 

(20) Are there supply limits on some of your vendors which force you to anticipate some of 
you* purchasing fetultmnents? 

(Please key in yes or no): yef 

(21) Do you carry seasonal inventories to absorb demand fluctuations? 
(Please key in yes or no): vejt 

To evaluate tkenetesstty of an aggregtie planning mod\ie;PROCTOR needs ike user's 
Judgement of the importance of the ttems affected of external constraints and an estimate of the 
percentage ofiM*a¥fi^^ •*-•'•*"* * '"' 

(22) Are items involved m external mteracttatt inw)6ttart enough "«* require a spedal system? 
(these itenis might be wfexp e hir ve of they coulrf^%seltOT) 



(Please key in yes or no): ves 

(23) Do you know what percentage of your items are affected bf these external interactions? 
(Please key in a value} 65 

A procurement aggregate planning module is needed. This is because you decided thai the 
external constraints of the purchasing department are important 

PROCTOR moosttgatos prodtutaggngatm oefbte etdtut Hiregate P&* feasibility: 
items and fantftts must be aggregated mfk a f fdtmaJatl tan fe eastblt. 



ytm\ 



(24) Can the items (and/or fimiftei) affected by exte* be grouped into 
product types t&o^d&g i» Mtmr ^om, demand petterfts, a»d7£ p^^ 
times)? ""' ^ "** '"'*' "' '' ''"■ *""'- **" 

(Please key in yes or no): y_ 

(25) Now how many product types are there? 
Please select one of (he foflowing: 

1 less than 11 

2 between 11 and 20 

3 between 21 and 50 

4 between SI and 100 

5 more than 100 



28 



(Enter here): 4 

Nottc* how PROCTOR makes conststtncy chucks btfor* amfttng an mum*: tt detects an 
inconsistency between the numb* of frmtlui andjhi n^*ffndm pw&* <*«*§• 
aggregatton. Mr. Smith feets that the numb* of product tybes it cmext and decides to change 
the number of famtites. 

Mr. Smith, I think I have detected an error. 

The number of product types exceeds the number of f unites. 

You may change one or more of the following. 

1 "between 51 and 100", the response to question 25 concerning the number of the 
product types of the purchasing department ,,,,.. H> .. , ,, />w ,,,, 

2 "between II and 90", the response to question 1ft concemifig the number of the 
families of the purchasing department 

(Please select one or more): J 

So far the following will be changed: The response to question 15 concerning the number of 
the families of the purchasing department. >» 

Do you want to change any more? 
(Please key in yes or no>. n, 

(15) Now Mr. Smith, how many families (groups of items) are there? 

Please select one of the following: 

1 less than 11 

2 between 11 and 50 

3 between 51 and 100 

4 between 101 and 250 

5 between 251 and 500 

6 more than 500 

(Enter here): 4 

PROCTOR acctpts th* change. Previous naluaUens ex* waaffectHmd PROCTOR proceeds 
to consider th* aggregate plan tn detail. 

(26) Mr. Smith, do you currently have an aggregate purchasing plan? 
(Please key in yes or no>{ 
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Mr. Swuh tnttrrupts tht stssten to print tnformatton conctrntng qutsttons 15 and 25. (Wt 
omit dttatls to savt spaa.) Nottet that changes ham bom corrtcttf mad*. 

Question 15 

concerns the number of the families of the purctnuing department 
response: Between m and zau 

Question 25 

concerns the number of the product types of the purchasing department 
response between 51 and 100 

PROCTOR conttmus tht stssten. .. 

It must dttermtnt an appropriate am* koriton ami ttwu period dMston for tht aggrtgatt plan. 

ThtsttnttrtntoantsttmattofthtnumbtrofiHurtabUsrteutrtd. 

An extsttng aggrtgatt plan cm somtttmts prottdt tnstght am approprtatt answers. 

(26) Now Mr. Smith, do you eorrefrtrf have an i{fre$ai* purchasing plan? 
(Please key in yes or no> n 

(27) Mr. Smith, can you give an estimate of an appropriate time horizon for an aggregate 
plan? 

Please select one of the following: 

1 less than 6 months 

2 between 6 and 12 months 

3 more than 12 months 
i not known 

(Enter here): 1 

Mr. Smith dtctdts on a hortxon of 6 months. PROCTOR knows that a hortxon of at least a 
year ts rtqutrtd when stasonaltttts art prtstnt (stt qutstton 21) «*** tUdtcatts tht error. 

Mr. Smith, I think I have detected an error. 

A time horizon of less than 6 months is inappropriate for a situation with seasonal 
inventories. 

You may change one or more Of the f oHowihg. 

1 "less than 6 months", the answer to question 27 about the length of the horizon of the 
aggregate purchasing plan of the purchasing department 

2 "present", the answer to question 21 about seasoneHnventories in the purchasing 
department 
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(Please select one or more): 1 

Please try again— 

OnNowMr;!^ 

aggregate plan? ' ."' ; 

Plewe select one of the following: 

1 lew than 6 month» 

2 between 6 and 12 month* 

5 more than 12 month! 
4 not known 

(Enter here): 4 / 

Mr. Smith cannot dtcuU on on Wmpmt* Aortam. PnQlCTOAp^i$sU*htrtx0n ofatlmst 

(28) It is common to do aggregate planning with a year horizon. Is ft ok to assume that the 
time horizon be more, than 12 months long? 

(Phase key in jm or no> ai 

Mr. Smtth cannot doctdt on w apjn<^<tmfi«toddmm.fJMCTVRx cm 

(29) What time period* doybu think you ihwU use to oi^ yobr timt horixon? 
Please select one of the foHowing: . ** 

1 1 calendar week 

2 2 calendar weeks 

3 3 calendar weeks 

4 4 calendar weeks 
5 1 calendar month 

6 1 calendar quarter 
7 1 calendar semester 

8 5 working days 

9 K) working days 

10 20 working days 

11 4-4-5 week division 
12 1 don't know 

(Enter here): 1£ 

(SO) It is common to do aggregate planning monthly. Is it ok to assume that the time horizon 
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be divided into 1 month periods? 
(Please key in yes or no): £ 

PROCTOR dtctda that an LP formulatUm u tnftastHt stncttht tsttmattd number of 
vartabltst*cttdrI9to,tkt assumed **M^mmf*th*yut^ 
eommeretal LP codt. 

A procurement aggregate planning module is infeasibte. The reasons for the decision are 
that 

1 the average number of the variables of the aggregate purchasing ptan of the 
purchasing d e p a rtme n t is mere than 1500. 

2 a procurement aggregate planning module is needed. 

The number of variables required for die aggregate plan makes tit computationally 

Impractical. The possibility of aggregating time periods in die planning horizon or further 

aggregating product types shoukV be considered. 

m It U wrnettrnes useful* segregate terns up to the prodocf level for reporting purposes. 

Would you tike product ag g r e gatio n to be considered for this reason? 

(Please key in yes or no): ! 

Mr. Smith requests that question 29 be reasked. An tmgtrttmt period utll decrease tkt number 
of variables required for the aggregate plan. (Detotis art omitted to am space.) 

So far the following win be changed: The rap question ,tl he; the time 

period division of the aggregate puftharir it 

PROCTOR reashs the qutstton, 

(29) What time periodi do you think you should use to divide your time horizon? 

Please select one of the following: 

1 1 calendar week 

2 2 calendar weeks 

3 3 calendar weeks 

4 4 calendar weeks 
5 1 calendar month 
6 1 calendar quarter 
7 1 calendar semester 

8 5 working days 

9 10 working days 

10 20 working days 

11 4-4-5 week division 

12 I don't know 

(Enter here): 6 
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PROCTOR dtltyi tht rtdtttrmtnatto* of tk f* 
poist middle rontt ffitcatting snstm 

possttfd when demand forecasts c*n be madt. 






PROCTOR returns to tts considerations of an aggregate pUm after concluding thatmtddle- 
range forecasting support u possible. (It continues f*«e^ ftmtflg<^ ro a,imm Mrt^ 
the session.) An aggregate planning module ts feasible and PROCTOR comments on the type 
of model that must be used. 

A procurement aggregate planning module is feasible. The reasons for, ifee decision are that 

1 the average number of the variables of the aggregate purchasing plan of the 
purchasing department U not mere than 1800. ' ■''* .'"" 

2 the average number of the constraints of the aggregate purchasing plan of fa 
purchasing department U not more than HOG. 

4 a procurement aggregate pluming module U needed. 




£iocurefnent arnountt 

".. wrap 

constramts. The 



Concerni l^l * he .- W» °C * Rrocurejnent aggregate pjanping 
for product type*, non-product families and non-product ^ " 
external constraints should be determined by means of a 
model should optimize holding and storage costs white obeying 
reasons for the decision are that 

1 oduteu feasible. 

2 external constraints ire present 

Product aggr*g*tton is needed when the aggregate plan ts feasible. In addition, a product 
disaggregation routtnt U rtqutr* for fiUocattng pte^ ^**Mt **/***,» family 
members. 

A component to handle product aggregation in the purtAailng department U 
needed. The reason for the decision is that a procurement i gfaj p'- L '"'" -u *i i. 
feasible. Concerning the details of a component to handle ptedoeF^ 
families that share common inventory characteriitics -and ' 
subject to external cc be 'q£SMWL^^ ^ 
aggregate planning, fht*l because external c»utrainiWpnise* H 
department and a pr oc ur e m ent aggregate planning module is f eatJMtA rno^ult for product 
disaggregation in the purchasing department i* imged. ? ThJs tobeauaf * module for 
product aggregation to needed ami a procurenmU aggregate planop 
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In another part of the a aton, PROCTOR constdtrs a lead ttnt determination moduli. A 
moduli w when wombk tamtitmtttoms vre present, vfrtaO) tf a significant 

numb* of urns i*< onrubl* lead tones* tflht surf j at* portant 

enough to report dost control. k 

(44) How would you characterize the variability of your purchasing lead times for most of 
your purchased item*? 

Please selerf one of the following: 

1 very constant 

2 reasonably constant 
S fairty variable 

4 extremely variable ' 



(Enter here>. $ 

(45) Now are the Items that exhibit variable letd-ttmei important enough to require close 
control? 

(Please key in yes or no): yes 

(46) Mr. Smith, can you give a percent estimate of the number of your items that arc 
affected 1>y lead time dependencies? 

(Pleaiekeyi 

A module for lead time determination is needed. The reason for the decision is that you 
decided that the items with variable toad timet of the purchase department arc important. 

With load ttm dtpmdtncUi, lotd ttm forecasting may bt posstbU. PROCTOR investigates 
dependencies. 

(47) Arid Mf. Smith, doe* the lead time vaflabifcty depend en the order size? 
(Please key in yes or no): n 

(48) Does the lead time variability depend on the season? 
(Please ley in yes or no): yes 

Vendor d*p*ndenaa exist only when there are multt-vendor ttens. 

(49) Do you have item, that cant it vendors? 
(Please kef In yef or 1 no* n. * -■—.*.- 



*in§ :W'ii 



(50) Mr. Smith, do you keep historical records of lead times? 
(Please key in y« or nofcyei 

A foretasting system is possible since seasonal dependencies extsi and since lead time records 
are available. 
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A lead time forecasting module U possible The reason for the decision is that lead time 
dependencies are present Concerning the details of a component to handle lead time 
determination: A lead time forecasting system should be imptemented for itwrn that have 
seasonal lead time dependencies. The reason* for the decision are that 
, la lead time forecasting module if possible. 
2 seasonal lead time dc 

PROCTOR notis that tt cannot evaluate support for long Itad ttmu strut tt dots not know tf 
long had ttmo itms art possible. (It determined that the states of long load time ttmswu 
unknown when u investigated tht necessity of a middle range forecasting. sjstonO 

A decision concerning the type of a module for long lead time det«rminatipn couW not be 
made The reason for the decision is that it U not known whethej- Jong Jead time items are 
present 



PROCTOR has completed the initial tnvesttgattonsjnto the componm of a planning and 
control system, tt roturns to tepUvel and asks for' forth* ttutructms: responses can b$ checked 
for correctness; ooaluattons can bo summartud. 

Mr. Smtth decides that KBS's leattttmes do not hem seasonal lead time dependencies; ho 
requests that quostton 44 bo changod. 

The current question numbers range from 1 to 72. Please key in the numbers corresponding 
to questions whose answers you wish to change. 
(Please key them in): 44 

So far the following wiU be changed: The response to question 44 concerning the degree of 
variability of the lead-times of the jujchaiing department 
Do you want to change any more? 
(Please key in yes or no): n 

Do you wish to delete any requests? 
(Please key in yes or no): n 

(44) How would you characterize the variability of your purchasing lead times for most of 
your purchased items? 

Please select one of the following: 

1 very constant 

2 reasonably constant 



so 



3 fairly variable 

4 extremely variable 

(Enter Here): 1 

An error: Mr. Smith r*qtust<d that tkt wrong qutstion btjt§$kt4. U tratm^ts PROCTOR 
tntktmtdMtofaehmgtmidn^ttastkM^lii^imiiiiymmg^ 

You are at top level Please select one of the following: 

1 quit 

2 continue the analysis 
Shelp 

'T Cn&UlgQ WlfWCTt 

summarize me analysts 

(Enter here): 4 

The current question numbers range from 1 to 72. Please key in the numbers corresponding 
to questions ; whole answers you wish to change. 
(Pleas* key them in): 4| 

So far the following will be changed: The response to question 46 concerning seasonal lead 
time aepenaencies itr tnv puitnaiuig ONpaiuiMH. 
Do you want to change any more? 
(Please key in yes or no): n. 

Do you wish to delete any requests? 
(Please key in yes or no): n 

PROCTOR must sttll r*uk qutstton 44. 

(44) How would you characterize the variability of your pOrthasmg lead times for most of 

your purchased items? 

Please select one of the following: 



1 very constant 

2 reasonably constant 
S fairly variable 

4 extremely variable 

(Enter here): J 

(46) Now Mr. Smith, does the lead time variability depend on the season? 
(Please key in yes or no): n 
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A lead ttm foreeasttng system ts inappropriate stnte there are now no Uad ttm dependencies. 
Nettce that PR&CTORwmmaU mlnamin fnatnitittm4im»fmmitmi»mi eomstekri '•' 
alternant* oartabU Uad ttm support. Em4Tt<nc*&ad : tMUttu**um u mnmms ort 
unexpectedly understock**; safety Uad ttmes an useful m prootdtng ti&smce against stock 
outs. 

(73) New do your vemlors o^ an " e merg e ncy " uudtkmffttttkfiimmif 
(Please key in yes or no): jn 

(74) And Mr. Smith, whenever the purchasing toad ttm la quite uncertain, a safety toad time 
can be added to the average toad time to take into acco m i l iW I lia wia ii ti M ij i tMiWd with 
toad time calculations. Do you favor the addition of a safety toad tine?' * - 
(Please key in yes or no> *j£ 

(75) Are there quantity restrictions sjsccbted with the emergency toad time? 
(Please key in yes or no): yes n < <* 

(76) Now Mr. Smith, U there a price increase associated with the emergency toed time? 
(Please key to yes or no): yes ?*?* "•->&■■■ 

PROCTOR has redetermined the details of lead ttm support. 

Concerning the details of a component to handle toad time aetermJiwttee* A safetf toad time 
should be added to your best current estimate of the procurement (eaaVlime when order 
amountt are to be determined. Emergency toad timet sheuM be used wdfiwlpi IHnu are 
unexpectedly stocked out This is because emergency toad-timei are pi iiato iJMtd watffcttons 
are present and you decided that the safety lead-times of the piiiiliastisj iMpaiiminr^re 
appropriate. f -:.r> -tN \*- - » -■ ' ' 

PROCTOR has nothing mare to do: tt awaits further tnstrutttons. 

You are at top level Please select one of the following: 

1 quit . ■ :■*.-,■. • ■?■ ' • :■■■■:/■'> 

2 continue the analysis 
Shaft 

4 change answers 

5 summarise the atwJrsfe r - • 

(Enterhcrekl ,■<•=-'■•- • .. «■>■•.. . 



■*■■■;•*.■■■■<. ■■■-■...■-«,.■;■■■.. ... ■;.-..'< j :„,.-,.'.■..■- '■'■.-,. -* :..■*.**-,. 5" -vS/V^- ;■*:.■■-, „■-■■.-,. jl\> ■.. .■ ■ -..■ *. ■■ -3$ # ' ..-I \ 

At>, SmiM ts not satisfied vtth the ettartir ytm ttm femd for the aggregate 7*** 
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requests that questton 29 be reasked. 

The current question number* range from 1 to % Please key In the numbers corresponding 
to questions whose answer* y«u wish to change. 
(Please key them in): g£ 

So far the following will be changed: The aniwer to question 29 about the time period 
division of the aggregate puftkasing plan of the ptarhasittg department 
Do you want to change any more? 
(Please key in yes or no): n 

Do you with to delete any tvauests? 
(Please key in yes or nofeg 

(29) What time periods do you think you should use to divide your time horizon? 
Please select one of the following: 

1 1 calendar week 
2 2 calendar weeks 
S 3 calendar weeks 

4 4 calendar weeks 

5 1 calendar month 

6 I calendar quarter 
7 1 calendar semester 
8 5 working days 

9 10 working days 

10 20 working day* 

11 4-4-5 week division 
12 1 don't know 

(Enter here): 5 

Unfortunately, Mr. Smttk forgot why such an aggregate tint period was chosen: an LP was 
tnfeastble unless ttme pertods or product types could be aggregated. 

A procurement aggregate planning module is infeasibte. This ii because the average 
number of the variables of the aggregate purchasing plan of the purchasing department is 
more than 1500 and a procurement aggregate planning module is needed. The number of 
variables required for the aggregate plan makes it computationally impractical. The 
possibility of aggregating time periods in the planning horizon or further aggregating 
product types should be considered. 

In ckangtng the number of ttme periods, Mr. Smith affected the evaluation of the feastbtltty of 
«» Hgregm plan md in turn* tketoalwaum fortktntddU rang* forecasting system. If an 



•..f-^j*'; 
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aggregate plan u tnfeastUe, u my he that no middle range forecasting system u required. 
PROCTOR, thnefort, rtcmputts epoJuetms (^forecojttngm 

mppoTttsn*4d4dforat#ntofd*mtm*ractton:md*l*. 

Concerning the detaili of a module for middle-range forecasting: The demand 
for product types, non-type families and non-family rwnHype items thouUte forecast by 
exponential smoothing. These forecasts may be duaggreg 

annual demands of members. Demand for slow movers can be forecast by exponentisl 
smoothing with a small alpha. This is bscausf a component to bandit %* forecasting of 
seasonal item. i. n«dsd «d s componem to ^mmmm^MiSmS^ ' 
possible and a module for the forecasting of slownwoying lams it needed and a module for 
the forecasting of slow-moving tarns is possible and a oar u^^t ordering 

constraints is feasible. ,r^»w< ^ 

Evaluations of the necessity of product aggregations to effected, Mr.^fste'4 $**§£$¥$ b* 
dots not want aggregation for reporting purposes. P R(XT OR conducts JJnduct aggregation 
ts unnecessary: why Of grogtU tfanLPU tnfeasmief 

(SI) It is sometimes useful to aggregate tarns up to the product level for reporting purposes. 
Would you like product aggregation to be considered for this reason? 
(Please key in yes or no>. q. 

A module for product aggregation is ujpecessary, TJjJsJp because I pjijcureroent aggregate 
planning module U infetsible. ., . i .. <•* 

PROCTOR returns to the top. 

And Mr. Smith, you are at top level Phase sekct on e of the ftrfjowiag: 

lquit 

2 continue the analysis 
_ SlwiJp '". "";■"' ■_ :V " 

4 change answers 

5 summarize the analysis 

(Enter here): 1. 

PROCTOR assumed a ttme horizon of more than 12 months frM<Uff*g*t* Atait M r. Smith 
specifies a horizon of f to 12 men bet thp 0^^^^j^^$aMm tkihf 

The current question numbers range from 1 to 76. Pleaw k^ in t^numDm corresponding 
to questions whose answers you wUh to change " *' 
(Please key them in): J7_ 
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So far the following wiH be changed: The answer to question 27 concerning the length of 
the horizon of the aggregate purchasing plan of the purchasing departmenL 
Do you want to change any more? 
(Please key in yes or no> n 

Do you wish to delete any requests? 
(Please key in yes or no): n 

(27) And Mr. Smith, can you give an estimate of an appropriate time horizon for an 
aggregate plan? 

Please select one of the following: 

1 less than 6 months 

2 between 6 and 12 months 

3 more than 12 fnontto 

4 not known 

(Enter here): £ 

Th* evaluations have nor changed. PROCTOR stmply reaffirm Us protons evaluations. 

A procurement aggregate planning module is infeuiMe. This U because the average 
number of the variables of the aggregate purchasing plan of the purchasing department is 
more than 1500 and a p ro c ur e m e n t aggregate planning module is needed. The number of 
variables required for the aggregate plan makes it computationally impractical f he 
possibility of aggregating time periods in the planning horizon or further aggregating 
product types should b#c!Wlrel. Concetning the d tfufc for middle-range 

forecasting in the purchasing department: The demand for product types, non-type families 
and non-family non-type items should be forecast by exponential smoothing. These forecasts 
may be disaggregated according to the relative annual demands of members. Demand for 
slow movers can be forecast by exponential smoothing with a small alpha. ThU is because a 
component to handle the forecasting of seasonal items in the purchasing department is 
needed and a module for the forecasting of seasonal items is p a component to 

handle the forecasting of slow-moving items in the purchasing department U needed and a 
component to handle the forecasting of slow-moving items in the purchasing department is 
possible and a procurement aggregate planning moduli is feasible and a component to 
handle Jomt brdi trmtb\ A cdmponew to handle product ition in 

the purchasing department a tihnecetsary. This Is because a procurement aggregate 
planning module is inf euibte. 

You are at top level Please select one of the following: 
lquit 
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2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 



(Enter here): i 

Mr. Smith rtmtmbors that ho did not tpoctft vhtthtr vendor contracts wore present. He hopes 
to rtmov4 tk4 tnftiutbUttj tvaltuum by compl4Uly sp^fytng tht prMtm. 

So far the following white changed: The response to ytett o rt 19 eoncemJnf vendor 
contracts. 

PROCTOR continues execution. .. . 

Homo that tMs change has oosoiutety n$ effect so tUeoabmtm. ThoeAomge re tk*J*mb* of 
constraints dm not affect the emtkmttons stncemagt?egm*^Uatmdy infioxM****}* 
too many oartaiUs. ■■-■■*.. 

(19) Art there contracts you sign with individual vendors whkhf tree you to define a fairly 
constant purchasing rate every month? 
(Please key in yes or no): a 

You are at top level Phase select one of the fatewing: 

Iquit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 

Mr. Smith finally talus tht mm roosonaoU course ofmtom WUk • UttU thought, he bosomes 
convinced that theu ts mm poouuet aggregation thon he k * o rtgtmo t ii specified. Ho therefore 
requests a change to question M9. 



So far the following will be changed: The answer to question 25 cenceming the number of 
the produo types of the purchasing department 

PROCTOR cemmues execution. . . . 

(25) And Mr. Smith, how many product types are there? 
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Please select one of the following: 

1 less than 11 

2 between U and 20 
$ between 21 and 50 

4 between 51 and 100 

5 more than 100 

(Enter here): J 

PROCTOR recomputes onlf affectedtvataatkM.lt 4og_m_r*oUm thtimutre session. Nam* 
that the problem ts nam feasible but uUk a different set of conditions: the lumber of product 
types has decreased and the number of ttme periods has increased. 

A procurement aggregate planning module Is feasible. This is because the average number 
of ttii viilirtili i i>rthi niietrti wiiiheiliiit sdenef the n w n hfiiJ r r dmai Miw n t li net move 
than WOO end the average number of the constralna of the eayoaift nenrheitng pkn of the 
purchasing de par tme nt is net more than MOO and a co mpon e nt to handle mtetfh*range - 
forecasting is possible and a procurement aggregate pfenning module is needed. Concerning 
the detain t# a nwdirie f or m id de s mage re«( ii rt e $ teihMpiiefjsitiag dtperttnente The 
demand for product types, non-type families and rwn^tm%«on^v»^ttamt shooW be 
forecast by exponential smoothing. These forecasts may be disaggregated according to the 
relative annual demands of m ember s . Demand for slow movers can be forecast by 
exponential smoothing with a small alpha. The teaeen* fer tb%des4ton are that 

1 a component to handle the forecasting of seasonal items is needed and a module for 
the forecasting of seasonal items is possible. 

2 a component to handle the forecasting of slow-moving items is needed and a 
component to handle the forecasting of slow-moving items is possible 

3 a procurement aggregate planning module is feasible or a component to handle Joint 
ordering constraints is feasible 

A component to handle product aggregation is needed. The reason for the decision is that a 
procurement aggregate planning module is feasible A co mp onent to handle product 
disaggregation » needed. This t* because a comp on ent t o handl e p eo d ut t a ggr e gation it 
needed and a p>u^ eu >om aayega*» pfcm^y«odsa*j»fauihla Gonctmmc the details of 
a module for product disaggregation: You should use the Knajsacfcof Jlax«me». l 
disaggregation scheme in allocating planned product type procurement amounts to family 
and non*farnt»y i t s m itiembua o d eee dpc t types. Thesf l elwrn es , woft best for sttnetjons with 
setup and holding costs such as yours. This frherenet a msrtess. fat s>ro<htct aUsagyrogadon 
in the purchasing department is needed and the estimated family and non-family item 
ordering cost of the purchasing department is more than two ckdburaed apaeaipemem 
aggregate planning module it feasible. Concerning the details of a component to handle 
product aggregation: Items and f amUiot that sasrs miwiim fciiousasiycharaetoristsci and 
demand patterns and that are subject to external co ns tr ain t s should be aggregated into 
product types for purposes of aggregate planning. The reasons for the decision are that 
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1 external constraints are present. 

2 a procurement aggregate planning module U feasible. 



Concerning the details of a procurement aggregate planning module Procurement amounts 
for product types, non-product families and non-product non-family items that are subject to 
external constraints should be determined by means of a linear pro*»mminr model This 
model should opbihte netting This is 

because a procurement aggregate planning module is feasible s^ e«eH»l constraints a*e 
present. 

You are at top level Please select one of the following: 

lquit 

2 continue the analysis 

3 help 

4 change answers 

5 uirmnaritethe analysis 

(Enter here): 

And t h$ tnt maun conttnuts 



A DESCRIPTION OF THI QUESTIONNAIRE 

In this chapter, we provide an overview of the strategy of the questionnaire as 
well as a description of its underfyinf structure. 

3.1 Classifying The Firm 

The first step in the analysis ii to classify the firm according to its activities, its 
degree of centralization and its size. This classification determines the strategy to be used hi 
the investigation. 

The strategy for the analysis is determined primarily by the activities of the 
firm. Possible activities include any combination of purchasing, manufacturing and 
distribution. (Notice that the purchasing activity must always be present since no firm is 
self-sufficient in raw materials.) Distribution affects procurement by creating unusual 
demands for goods: individual stocking points occasionally decide to hold items Independent 
of the demand of their customers. In such cases, the procurement department can find it 
impossible to predict future requirements. Issues such as transportation costs become 
important when distribution activities are present. 

If the firm's activities include manufacturing, separate purchasing support is 
feasible only if demands are independent of the production process. Manufacturing 
situations with independent demand usually involve simple one step processes like the 
manufacture of coffee cups or the packaging of pills. For a situation with complex 
production sequences, even though the demand for end items is smooth and predictable, due 
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to explosions and assembly lead tiroes, demands for raw ■aateriais will be lumpy and erratic 
(dependent). A material requirements planning system wuTtheft^be required. 

Another issue is the degree of centralization of Ihe decision process. With 
decentralized control (several departments centroNing^ similar Asms), centralization can result 
in decreased costs. Combining departments usually ranks m savings m payroll A saving in 
inventory investment U possible when there Is an overlap in ttttas being handled There are 
also potential savings in ordering costs and possible discounts resulting from the joint 
ordering c€ items. 

The third issue is problem size which te measured in terms of the number of. 
items handled by the firm- With many items, issues of sfgreg atk w beeome iroportatit But 
if a problem is small, it may be solved manually or by linear prog r a mmi ng techniques and 

=?■' '" ■ '-'' -:'■■ '■■. ' ft * . 

f. -.■■•■■ m> 

hente, issues of aggregation do not arise. 

There is a different problem for each combination of these bask characteristics. 
And each problem involves a different methodology. In this thesis, we have considered only 
one branch of the tree of possible situations. We solve the pmbksn ft* a firm whose only 
activity is purchasing, which has centraHted control of the psnffraiina* process and which 
handles a substantial number of Hems. We will assume this problem for the rest of this 
discussion. 

3.2 The Investigations Oatlined 

Figure 3.1 tfaistrates the underlying structure of tjhc questionnaire Tho figure 
shows the kinds of facts that are involved Id the investigation and their relationship to other 
facts. A clockwise traversal of the graph will reveal the overall structure of the 
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questionnaire The questionnaire proceeds by investing: joint ordering interactions, 
family aggregations, •xternal constraints, product aggregations, procurement lead time 
characteristics, vendor characteristics, costs involved in ordering and holding goods, and 
customer demand characteristics. 

Joint ordering interactions are investigated first In determining the existence of 
Joint ordering interactions, questions concerning Joint of economies of tramportation f rom 
vendors, quantity discounts for multiple items ordered from vendors, ami, shared ordering 
costs are considered. Joint ordering tupport win be considered feaiiblt onty when these 
interactions exist and only if items involved in these Interactions are important. Jotojt 
ordering support is possible when items involved in Joint ordering interactions have timjfer 
inventory characteristics. Items may then be aggregated into fainibei for purposes of Joint 
control The user is asked to estimate the number of famjMei j^i^ ar^ the percentage of 
items not in families. These are used in an evaluation of feasibilttj in terms of problem sige. 

Family aggregation to coostdered primarily for to use in the Joint control of 
items that exhibit Joint ordering interactions. But items may also be aggregated fur 
reporting purposes. This possibility to investigated if Joint ordering support to tof easible or 
not required. 

External constraints are investigated next. An aggregate plan to required if one 
or more of a set of constraints - storage, financial, seasonal or contractual - are present, arid 
if a significant number of items are affected by these constraints. 

To evaluate the feasibility of an aggregate plan, PROCTOR requires an 
estimate of the number of variables and constraints required in the linear program 
formulation (LP). The user to asked to Judge the witablaty of various time horfeans and 
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period divisions for the LP. (PROCTOR is careful to suggest a horizon of at least a year 
when seasonalities exist) An aggregate plan usually requires more aggregation than family 
aggregation can offer: product aggregations are therefore considered. Product aggregation 
is possible only when there exist sets of families and non-family itemi with similar costs, 
holding costs, lead tunes ami demand patterns. The user asked lo estimate the number of 
product types that result from aggregations the number of types enters into the 
determination of the number of variables in the LP. 

Product aggregations are considered both for the aggregate plan and for 
reporting purposes. A disaggregation routine is required when aggregations are used for 
planning purposes. Item ordering costs enter into the determination of a suitable component: 
equalization of run out times wilt be appropriate for small setup costs. Otherwise, a routine 
tike Knapsack <Bttran and Hufty will be suggested. 

Having decided on aggregations, the next step is to examine the inventory 
characteristics. These are lead time characteristics, vendor characteristics and order 
characteristics. 

The first consideration is variable had tones and their dependence on order size, 
season and vendors. Special procedures win be required to control items with variable lead 
times. When dependencies exist and lead time records are available, lead time forecasting is 
the appropriate procedure. For example, with a lead time dependence on season, it may be 
possible to predict lead times by agression or exponential smoothing. Certain items may 
have variable lead times with no obvious dependence. These can be controlled by adding a 
safety lead time to an estimate of their lead tune or by taking advantage of emergency lead 
times/Alternatively, item* may be dsuified u class A and be placed under strict 
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management control As part of the lead time investigations, PROCTOR considers items 
with very long lead times. Imported items may rehire dose supervision, espedatly if they 
are high usage items or art expensive. 

Another consideration is vendor tradeoffs. ,^ien vendorjLof' for different prices 
and lead times, it may be feasible to set up a system ^^.p^^^^ilmfl analysis and 
then select the appropriate vendor. Questions concerning the availability of records o/ s 
vendor performance as well as the user criteria for vtndor election are posed to determine 
the type of procedures to be implemented. If the user crilarj| for vendor selection is quality, 
for example, it may not be reasonable to implement a system whose selection criteria is pjr^e. 

The system next considers support for the determination of order quantities. 
Questions designed to characterize ordering oasts, holding costs and purchasing costs, and to 
determine the applicability of the Economic Order Quantity (EOQ) formula are posed. 
First, the properties of relevant costs are obtained from the user. TJbt user mheri lead to 
investigate the EOQ, formula as it might apply to hu situa^. Art EOQ.routine U possible 
if setup costs are not too small, if the relative magnitude of setup cost* te shotting costs is 
reasonable, and if a middle range forecasting system is possible. Special EOQ, formulas are 
considered for situations with family aggregation, discounts and non-instantaneous 
replenishment rates. The EOQ, will not be appropriate for some items. For these items, the 
system suggests alternate procedures such as ordering up to a monthly maximum or 
continuous control. 

At this point, the overall framework of the system has been determined. 
Possible aggregations, disaggregating procedures and special control features have been 
characterized. The next step is to study the demand since this win influence the, forecasting 
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iTttem which U bwic to adequate control 

First, questions of seasonality and trend are examined. If the percentage of 
seasonal items is insignificant, limited support may be offered, or if only one seasonal 
pattern exists, a special support system may be adequate. Exponential smoothing with 
seasonal adjustment requires seasonal indtcet the user is asked questions concerning the 
availability of these Indices or dafr to compute these indices. If limited sales season items are 
present, it may be advisable to offer support which wftl prevent overstocking prior to the 
stack season. The type of support offered li determined by the cost of overage: loss in 
salvage, storage costs or toss due to scrapping. Items with trends wtfi requite forecasting with 
trend adjustments. 

Routines are considered for special items. If fashionable items (high 
obsotesence, short life) ire common, the system should handle them. Promotions and 
advertising wot affect the accuracy of the forecasts, ft effects are predictable or if there to 
heavy investment in advertising, support procedures should be Incorporated. Regression wlH 
then be mandatory, and If data avaitability is poor, a tradeoff between the cost of 
implementation and cost due to poor control will have to be made. If prototype life »nd 
death curves exist, support in predicting item growth i and decay may be possible and 
desirable, especially If Items exhibit a short life span. Slow movers can be placed in the class 
C category. Items with erratic demand will require continuous control If unusually large 
demands occur, these should be filtered out by a special system. 

The strategy is to determine which features would be desirable and are possible 
in the system. In evaluating the necessity of a component, the system considers the user's 
judgement of the relative i mp orta n ce of the items. 
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Data availability is the moit important consideration in evaluating the powibility 
of forecasting support since data is critical to forecasting. For example, without at least three 
planning horizons of data, regression will not be possible. To handle seajonali% on« year of 
data is normally required to determine seasonal indices. A managerial estimate could be used , 
when data Is unavailable, but due to inaccuracies, system performance may be poor. 
Questions concern the availability of demand and sates records, the cost of data creation, the 
accuracy of records, the availability of back order records, the length of the history available 
and the periodicity of the history. Feasible techniques are determined from answers to these 
questions. 

This completes the investigation* into system components. The reader may have 
noticed that all criteria so far have been factual and have involved no biases or preferences. 
During the investigation, the system asks the user for his judgements concerning the 
importance of certain items in the firm and for his preferences for the way procedures are to 
be implemented. 

SJ A Brief Summary 

The questionnaire strategy can now be summarized. By interrogating the user, 
the questionnaire determines the desirability and the feasibility of a set of components in a 
planning and inventory control system. Feasibility decisions are based on size and data 
considerations. Components are selected by taking the user's preferences into consideration. 

The questionnaire is educational in nature. It presents the approach for the 
solution of the problem to the user and guides the user in the investigation of various 
alternatives. This strategy is reasonable since only the user can provide data for his 
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situation. 

Validity checking is important to questionnaire strategy. The validity of 
answers is checked both to insure that a believable situation is being presented and to insure 
that the user understands the questions. 



chapter * 

This chapter extendi the description of chapter f. £y introducing a aeries of 
refinements to the description of the previous chapter, we derive a model of the 
questionnaire that is a basis for the implementation to be discussed in Chapter fi. 

4J Pacts Are Different From Answers 

In developing the model of the questionnaire, we found that it was convenient to 
make a distinction between the user's responses to queition» and {he facts derived by the 
system. PROCTOR asks questions to obtain the user's perception of the value of some fact 
These responses are checked for correctness and consistency and only then are they used by 
the system to determine facts concerning the problem. 

The distinction simplifies the representation of the questionnaire. It allows us to 
organize the questionnaire in terms of facts to be derived and not the questions asked to 
derive these facts. For example, in determining the existence of arnmon ordering costs in 
the firm, we may simply ask the user if they exist If the user cannot supply an answer, we 
can ask if complex orders or multi-item orders exist to perhaps deduce that there are 
common ordering costs. In describing the questionnaire, we need only mention that the status 
of common ordering costs must be determined. How we determine this fact is another Issue, 

The distinction has other implications. The user can change his response to a 
question but he cannot directly change the value of a fact jBy keeping facts separate from 
responses, we can minimise or eliminate the impact of changes in the user's responses. 
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Suppose that we had determined that the firm has items with multiple vendors from the 
response that the average number of vendors wppJrmt; an temU "between 10 to 20". If the 
user changes his response to "between 20 to 30", the fact that there are multiple vendor items 
does not change. 'The change in the uter** response ha« rw effect on the u»e of the mukl- 
vendor item fact in other iituattom. 

By making a distinction between facts and responses, we can simplify the 
checking process. Since the user can only change answers, PROCTOR need only check the 
consistency of facts at the response leveL A response b assel&l into the data base only if it 
is syntactical correct and consistent with other responses. All facts derived from these 
responses can be assumed to be correct 

4.2 Two Categories of Facts 

Two categories of facts can be identified in the questionnaire The first, the 
tniel fact, describes OoaBtaHvi characteristics of the firm. A type 1 fact wilt assert that lead 
times are variable or that quantity discounts are posiibVln purchasing iterro from vendors. 
The faxM type of fact, the type 2 fact, is more quantitative. These facts describe 
quantitative information td be uied in th« mkiaiton rf'cwnpontnti for the procurement 
system ind in the determination of other fads. A type 2 fact can state the length of a 
planning horizon, the number of families possible* by aggregation or tne percentage of items 
exhibiting seasonalities. '' *'' *'" ' 

figure 4J gives a fist of type 1 facts to be determined when examining a firm. 
The indentationi show the relation of these type 1 facts to'the overall structure of the 
questionnaire. Notice that all facts are qualitative and characterize the firm. Notice also that 
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Firro 

Activities of the Firm 
Organization of the Firm 

Single or Multi-department 

Centralised or D*owUr»ll»d Control 
Departments 

Overall Problem Size 

Existence of Item Interactions 

Quantity Discounts 
Shared Ordering Costs 
Existence of External Constraints 
Storage constraints 
Supply Limits 

Contract Commitmenti 

Inventory Characteristics 

Lead-time Characteristics 

Degree of Variability of Lead-time* 
Dependence on Season, Order-size and Vendor 
Existence of Imported or Long Lead Time Bams 

Vernier Characteristics 

Existence of Price Tradeoffs 
Existence of Lead Time Tradeoffs 

Order Characteristics 

Existence of Complex Orders 
Existence of Extremely Expensivs Items 
Demand Characteristics 
.; Seasonalities 

Limited Saks Season Items 

Trends 

Erratic Demands 

Slow Movers 

Issues of Promotion and Advertising 

Fuhionable Items 

Item Life Patterns 



A List of Type 1 Facts to be Determined 
While Examining the Firm 

Figure il 



so 

figure 4.1 does not list specific quantities such as the number or percent of items that exhibit 
these characteristics. 

Figure 4.2 gives examples of groups of type 2 facts that are used in the 
evaluation of components in a procurement system. Type 2 facts can be determined more or 
less randomly since the absence of a value for a type 2 fact U not as critical for the 
successful completion of the session. A fact may be derived at a later time and incorporated 
into the evaluation of a component 

This categorization of facts into two types is Important for the model of the 
questionnaire. In a later section, we will extend this categorixation and give rates for 
deciding when facts are type 1 or type 2. 

4 .8 A Mappingt The Components of a Procurement System and the Strategy for 
Investigating the Firm 

The questionnaire has an underlying tree structure. Consider figure 4J which 
gave a list of type 1 factt to be determined during the investigation. Figure 4J shows groups 
of related type 1 facts that describe different aspects of the firm. Facts describing the status 
of truck load economies, Joint quantity discounts and shared ordering costs are all related to 
the Joint ordering interactions of the firm. Facts concerning price and tead time tradeoffs 
describe the firm's vendors. 

The questionnaire is structured by combining procedures for determining these 
type 1 facts into towage* activities. The investigate Joint ordering interactions activity has, 
for example, procedures to determine the ititus of Joint economies of transportation, the 
status of Joint quantity discounts and the existence of common ordering costs. Investigate 
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Aggregate Plan 

Percentage of Items Involved in External Interactions 

User Judgement of the Importance of the Items 

Estimated Number of Types Involved in the Aggregate Plan 

Time Horizon 

Periodicity * 

Evaluation of the Pouibility of a Middle Range Forecasting Sysjem 



Middle Range Forecasting Sjstern 
Time Horizon 
Periodicity 

Percentage of Semsonal Items 
Percentage of Umited Sate* Season Items 
Percentage of Items with Trends 
Data Availability 



Order Quantity Calculation Routine 

Evaluation of the Pouibility of an EOQ, Routine 

Percentage of Expensive Items 

Percentage of Slow Movers 

User Preference for Alternate Procedures 



Groups of Type 2 Facts Needed for the Evaluation 
of Components of a Piwuremeot System 

Figure t? 



*2 

activities may be further structured by combining low level investigate activities into more 
general investigate activities. Thus, the activity that investigates inventory characteristics 
will investigate lead time characteristics, vendor characteristics and order characteristics. Hie 
ultimate investigate activity is the acUvity to Investigate the firm. 

The hierarchical structure of investigate activities is shown in figure 45. Type 1 
facts can be determined by each activity of flits tree. At the investigate the purchasing 
departments activity, we determine the number of purchasing departments. At the 
investigate the demand characteristics activity, we determine type I facts concerning the 
demand patterns for items in the film 

The questionnaire is also structured an* » of type 2 facts. Consider the 

basic components of a procurement system. According to Hax's methodology, they can 
include 

- a method for family aggregation 

- a method for type aggregation 

- a family-item disaggregation routine 

- a type-family disaggregation routine 

- an aggregate planning procedure 

- a lead-time forecasting module 

- an order quantity calculation module 

vendor selection routine 

- a medium forecasting system 

This list could have been further refined. An order quantity routine can include an 
Economic Order Quantity calculation routine, a routine for expensive items and a routine 
for slow movers. 

Groups of type 2 facts enter into the evaluations that occur when PROCTOR 
considers these components. When we consider aggregate planning support, we require facts 
concerning the percentage of items that are affected by external constraints, the time horizon 
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Investigate the firm 

Investigate the departments of the firm 

Investigate the purchasing departments of the firm 
Investigate a particular purchasing department 
Investigate the item constraints 
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Investigate *« extemaicoattreints ,,... 
Investigate the inventory characteristics 
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Investigate die costs and order characteristics 
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The Structure of Investigate Activities 
Figure 13 



and periodicity of the aggregate plan, the number of product types as well as a Judgement 
concerning the importance of the items that are affected by external constraints. We call 
groups of evaluation! consttUr activities. When we evaluate the feasibility, necessity and 
type of aggregate planning component, we .are- realty ccmtdtrtnf rht a gg i cg atc : • planning 
component. 

Consider activities may be structured according to dependencies that exist 
between modules in a general planning and eo^tt^^^fiiM.' 0M^0n 4.4.) From figure 43 
and figure 4.4, we can set that thete is a one to one con e ipo ndence between the structure of 
investigate activities and the structure of tohtider activities. In the "context" of each 
investigate activity, certain consider aettvMes tan be mtdated. In Investigating external 
constraints, for example, we naturally consMer in aggregate planning c ompo n e n t, a product 
aggregation component ana a product atsaggregatton component. 

The underlying itroctuw of the quwttonnahe ihouW now be clear Figure 43 is 
an overall plan for the investigation of the firm :*1H&ii&0Hjj to* plan, type 1 facts are 
determined. Considerations into components of the procurement system are initiated 
depending on the value of these type 1 facts. To evaluate components, type 2 facts are 
determined. The implication of the model i« th»t no? additional structure is needed for the 
evaluation of component! of the procurement system. We use the tree of investigate 
activities as the plan for the Investigation of the firm. Investigate activities can initiate 
other investigates as well as considerations into co mp o nents for the procurement system. 

It may seem at this point that the questionnaire is completely hierarchical: that 
individual investigations may be done independent of other investigation*. Unfortunately, 
non-linearities do exist 



55 



Firm system 

Department system 
Planning module 

Family-Hem iggTegttton^isaggregation routine 
Family aggregation method 
Family-item disaggregation method 
Aggregate planning routine 
Product-family disaggregation routine 
Product aggregation method 
Product disaggregation method 
Scheduling routine 

Lead time forecasting routine 
Vendor selection routine 
Order quantity calculation routine 
Forecasting system 

Medium range forecasting system 
Short range forecasting system 



The Structure of Component* of a Procurement System 
Figure 4.4 
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As an example, consider the evaluations for the type to family disaggregation 
module. In deciding on a Knapsack or equalization of run out time disaggregation method, 
we examine both holding costs and ordering costs. (For small ordering costs or for situations 
where ordering costs are small compared ttt holding costs, equalization of run out times is the 
appropriate disaggregation method.) Notice, however, that costs are usually determined by 
the activity that investigates costs. When ordering costs are used in the evaluations for 
disaggregation, they are used "out of context". This non-linearity will complicate our theory 
only slightly. Its implications are described in a later section. 

44 Type 1 and Type 2 Facts: Their Impact on Strategy 

We stated previously that type 1 facts are qualitative facts concerning features of 
the firm. Type 1 facts influence the strategy of the investigation. But how? 

Consider some typical type 1 facts. They can describe the size of the firm, the 
activities of the firm, the variability of its procurement lead times and the demand 
characteristics of the firm's items. These facts influence the strategy of the questionnaire. A 
one item system, for example, is so different from a multi-item system that a completely 
different strategy for investigation is appropriate in each case. The strategy for 
investigating item demand is influenced by type 1 fads concerning seasonal items and items 
with trends. 

Depending on their detail, type 1 facts are derived at different levels in the tree 
of figure 45. Characteristics concerning the bask organization of the firm are derived at the 
upper level investigate the firm and investigate the departments activities. The more 
detailed fact concerning the variability of lead times is derived at the low level investigate 
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lead time characteristics activity. The scope of a type 1 fact seems to correspond to the level 
at which it is derived in the investigate tree. Thus, the fact concerning the variability of . 
lead times will influence the strategy of investigations into lead times. The fact concerning 
the activity of the firm will influence the strategy of all activities below the investigate the 
firm activity. 

Type 1 facts influence the strategy by determining the procedures to be used in 
an investigation. Thus, the procedures that determine facts and evaluate components in the 
investigate external constraints activity depend in part on the status of external constraints in 
the firm: only a minor amount of processing is done by the investigate external constraints 
activity when external constraints are absent The procedure for an activity depends on only 
a limited number of facts (two or three at the most) and only on features that are necessary 
to distinguish between the various procedures for the activity: the procedure for the 
investigate external constraints activity will not depend on the degree of variability of lead 
times. 

While type 1 facts determine strategy by influencing the selection of a procedure 
for an activity, type 2 facts do not Type 2 facts are data that is used during the execution 
of a procedure. Suppose that we have decided that an aggregate purchasing plan it 
necessary since a significant number of items are affected by external constraints. We must 
next determine if it is actually feasible. The number of variables in the linear programming 
formulation (a type 2 fact) enters into this evaluation. We make our decision by comparing 
this number with some upper bound that is determined by limitation* of currently available 
LP code. The number of variables in no way affects the selection of a procedure for 
evaluating the feasibility of an aggregate purchasing plan. We use the same procedure 
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regardless of its value. 

Other type ? facts are similar. The mimbtr of families resulting from family 
aggregation determines if a procedure for Joint 1 ordering Hi realistic. But it does not 
determine the procedure for making this fettttrtfity decision, the type 1 fact concerning the 
possibility of aggregating items into families determines the procedure used. If family 
aggregation is impossible, the procedure is to limph/ assert that Joint ordering support is 
infeasible 

We now see how this deicrlption of type 1 and type 2 facts relates to the 
categorization described tn section 12. Type 1 facts influence strategy and by their nature 
they must be qualitative. We need not deal with exact numbers but with ranges and 
generalization* when deciding on a procedure for aft "activity.' In selecting a procedure, 
knowing we have many or few items is Just as useful u knowing we have 4 or 4*7 items. 
Type 2 facts enter directly into evaluations and are by their nature quantitative. To evaluate 
the feasibility of a component to handle Joint ordering interactions, we need at least an 
estimate of the percentage of Hems involved in these interactions. 

Type 2 facts never influence strategy. Type 1 f acts, however, may both influence 
strategy and enter into the evaluation of components for a procurement system. Consider 
again the evaluations for the aggregate plan. A procedure for determining the details of the 
aggregate plan depends on whether external constraint! even exist (a type I fact). In 
determining the details of the plan, we need both type 2 facts such at the number of items 
involved in external interactions and type 1 facts describing the actual constraints. The latter 
fact determines the kinds of constraints to be Included tti the t* formulation. 

The rule for classifying a fact as type 1 or type 2 U now dear: if a fact enters 



into the selection of a pnxedure for an activity, it is a type 1 fact otherwise it U type 2. 
Retponiet are type 2 facts since they never enter directly into the tf taction of a procedure. 
Notice also that All evaluations arf type 2 ^nce they cannot determine strategy. If 
evaluation! were type 1 f acts, it would not be possible for RRQCTQ* to continue an 
Investigation without making a, definite decision at mch step in the investigation. The 
distinction to be made is that facts related to the PQMtyl tytv of a component influence the 
strategy but the actual evaluations of the component do not. So »n aggregate pUn is 
possible if external constraints exist Type 2 f *c$ determim ^ an aggregate plan U actually 
required. The status of external constraints Influence* the wbsefnent strategy and launches 
an investigaticm into a medium rsjige forecauting iy»ttm. 

The categorization of type 1 and type % has implications to changing answers. A 
Change in a response can affect the value of a type 1 or type 2 fact or both. If a change 
affects *. type 1 fact, then certain other f act* may bt invM*d»ted- Fa^deternuned during 
the evaluation of an aggregate plan become invalid if constraints do not exist Vendor 
tradeoffs are impossible if multiple vendors do not exist A type 1 fact may affect a type 2 
fact directly. If the type I fact Js used In the determination of a type 2 fact (as U the case 
with the evaluation of the, details, of an aggregate pfenning module), then the value of the 
type 2 fact U affected directly. A type 2 fact may enter in the determination of either type 1 
or type 2 facts. A change in the type 2 fact will affect Owe facts directly. 

4.5 C h angin g Answers; Env iroeroeaU and DiieclD ependenfle i 

In the previous section, we described how a type 1 fact affect* the selection erf a 
procedure and how a type 2 fact enters only into the execution of Jhia procedure. We also 
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described the Implications of this categorization of facts to chinking answers during the 
investigation. In this section, we f ormtlire th«e rwtkmi 

As an example, consider the investigate lead timet activity. The procedures to 
be used in the investigation depend on the degree of variability of lead times and on the 
status of lead time dependencies, ft lead timet are conttairt, vre can slnipiy deduce* that a 
component to project lead timet will not be required. Suppose, however, that ttiere are 
variabilities. Lead times may then depend on season, on orde* size and on vendors. These 
dependencies can exist illy when lead times are variable. Irt addition, vendor dependencies 
can exist only when the firm hai multi-vendor items. 

There are various approaches to selecting a component to handle variable lead 
times. A forecasting module ii possible If lead time dependencies exi*t For Variable lead 
times with no dependencies, a possible solution is tb^atd 1 safe% leadtimeld the belt current 
estimate of the itim lead time The procedures for determining the possibility, necessity and 
type of a component for forecasting lead times are determined by the lead time dependencies. 
When dependencies are absent, the procedure < [ W to limply aisert that forecasting ii 
impossible. When the status of dependencies is uninown, we Cannot male any evaluations. 
We simply assert that evaluations cannot be made. More complfcated procedures ire used 
when dependencies do exist 

In evaluating the necessity of a forecasting component, we use facts like the 
percentage of items that exhibit these dependencies and their relative dollar value (either 
actual or based on user judgement). The evmluatlon of the prtssibittty of a co mpo ne n t Is 
determined by the availability of lead time records and the evaluation # th% necessity of the 
component The type of a forecasting procedure is determined By th* details of lead time 
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dependencies, by the availability of lead time records and by the evaluations of the necessity 
and possibility of a component 

These relations are illustrated in figure 4£ The double arrows show how facts 
depend on the type 1 facts thai enter into the selection of procedures to determine these facts. 
The^ingle arrows show the 'direct dependency of a f act on |a<t* that are used in its 
determination. 

Consider what happens When we propose to change the fat* concerning the 
variability of lead times. The facts concerning dependencies may now be invalid. AH facts 
that depend on these dependencies become questionable. These facts all depend on the 
tnvtrormtnt in which they were determined. The environment is determined by the values 
of type 1 facts that enter into the selection of procedum that determine these facts. 

Suppose instead that the percentage of items affected by lead tane dependencies 
is altered. The evaluation concerning die necessity of a component is directly affected when 
we change this type 2 fact. The evaluations concerning the possibility and type of a 
component ate also affected. The evaluation of necessity diptntU dtrtctly on the percentage 
of items affected; by lead time dependencies; The evaluations concerning the possibility and 
type of a component have a dfract dtptndency on the evaluation of the necessity of the 
component. 

Notice the implications. By changing type 1 farts concerning the status of lead 
time dependencies, we can immediately invalidate groups of other facts. These facts are 
determined by procedures that were selected because lead tune dependencies were present If 
lead time dependencies were absent, these facts would never have been determined unless 
alternate procedures required them. When dependencies are absent, there is no fact 
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concerning the percentage of lead time dependent itwru. Facts are not just Invalidated: new 
facts become possible. A new fact might be determined by a newly selected procedure. In 
contrast, when we change the type 2 fact concerning the percentage of lead time dependent 
items, we do not question the existence of facts that depend directly on this type 2 fact The 

facts are simply Invalidated since some inputt have changed. To recover, we need only 

.'. ... ■ ■ : . . '} 

recompute the facts that depend on the changed type 2 f|ct 

:i .,'• . ' " ■■"-■ 3 

Now consider the sequence of acttvtties that lead to the determination of the 

~S ■ '"■' ■■'■ St '''■■ 

percentage of lead time dependent items. The procedure for investigating lead times 
depends on the activitie^of the firms* For a procurement situation, we need tanty investigate 
procurement lead times. % manufacturing activities exist, we mutt investigate both 
procurement and production toad timet. Ttot procedure for investigating toad times in a 
procurement situation U to limply consider a toad time determination component. The 
procedure for this activity depends on the variability of toad times. If lead times are 
constant, the procedure is trivial for variable tead times, we determine *h« necessity, 
possibility and type of forecast!* component for toad times. The procedures for these 
activities depend on toad time dependencies. In deter**** the necessity of ihe component, 
we determine the percentage of items that an 

Figure 16 shows the sequence of activities that toad to the determination of the 
percentage of toad time dependent items. It shows also how facts enter into the selection of 
procedures for these activities. (These are illustrated by the double arrow*) We see that the 
environment of a fact is determined not only by the facts that enter into the selection of a 
procedure for the determination of that fact, but also by all facts that enter into the selection 
of procedures of activities that toad to the determination of that fact The environment for 
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the percentage of lead time dependent items includes f icti concerning the activities of the 
firm, the variability of lead times and the status of lead time; dependencies. 

A type 1 fact can appear in the environments of both type 1 and type 2 facts. 
These facts can be invalidated by changing the type I fact By invalidating a type 1 fact, we 
can similarly invalidate other type 1 and type 2 facts. The process eventually terminates. 
New facts are now possible since different procedures may now be used. Clearly the side 
effects from changing a type 1 fact can be extensive enough to warrant a review of the 

■: ,- r '?*f » (-■-■'.'■-..J .; \ -.*■ 

session. In reviewing the session, we redetermine the vakm of all fix* whose environments 
have changed. (This does not imply that we reask an questionsQ We also ? determine new 
facts that appear in procedures that are now selected. 

It is usually unnecessary to recompute the session when we change a type 2 fact 
In determining the effect of a change to a type 2 fact, we trace back throufh direct 
dependencies to find all facts the depend either directly or Indirectly on this type 2 fact 
These facts can then be sorted according to their dependencies ami are recomputed. 

In changing a type 2 fact, we may indirectly change the value of a type 1 fact 
For example, many type I facts depend directly on responses which are type 2 facts. We 
revert to the type 1 change procedure when a change in a type 2 fact results in * change to a 
type 1 fact 

We mentioned previously that non-linearitiei , «kt in the questionnaire. Suppose 
that while investigating lead time vendor dependencies, ^ : de*rmine the status of multi- 
vendor items. The environment for the status of muttf-vendor items will then include the 
fact concerning the variability of lead times. Clearly nwW-veodor kerns can exist regardless 
of the degree of variability of lead times. The problem arises because the stajus p| multi- 
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vendor items is determined "out of context". The environment for this fact would be correct 
if the fact was determined during the invention of vendor tradeoffs. The problem is 
solved by specifying an explicit environment for facts that can be determined out of context 
The value of such a fact is assumed to depend on only the expHctt environment and not on 
the computed environment 

« And Other things 
4B1 the Baste Activities 

In the above the discussion, I have made reference to activities that appear in 
the questionnaire. 

The basic activities in the questionnaire are investigate, determine, ask, consider, 
check, and explain. Notice that we have ho activity for evaluations. I have chosen to use 
determine for this purpose: to evaluate a component, we actually determine the evaluation of 
that component. Each activity depends on zero of more type I facts that determine the 
procedure to be used for its execution. 

The procedure for ask is trivial Ask merely presents a question to the user, 
checks the answer for syntactic correctness and consistency, ami asserts it into the data base 
with the correct environment Ask will not reask a question if it knows an answer and the 
answer is still valid, ie. its environment U still valid. 

The procedure for a determine consists of a set of methods for determining the 
value of a type 1 or a type 2 fact Like ask, determine will first access the data base to see if 
the fact has a valid value. Determine simply exits if a valid value exists. Otherwise, 
determine trie) each method until it determines the value of the fact Determine asserts the 
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determined value of this fi^ into the date bue wtth a ragprd «f Om M^vlrennMiU and direct 
dependencies. There are direct dependencies between^** fact to be determined and all facts 
that are referenced during the executkm of the ratthod*. 

Check dees consistency checking far the system It ituaed by the ask activity to 
verify that a response to se m i nnct l ly correct and rnnHteef with other ^formation. The 
recovery for an inenmht e n cy is to either reask. the^uetttao or to allow the user to change a 
previous response. 

Consider initiates evaluation* into cwnponenu. U* procedure is a list of 
determ ine activities for facts concesf^ the evahis^ 

necessity of the components. Investigate is a set of ordered determine, consider and 
investigate activities. 

Explain u a simple activity that merely ask* the user if he needi an explanation 
and if so prints out text Explain can bt mvoked by srty activity. 

i&2 Facto and Their Relation to Entities 

We have discussed the basic process of determining facts. As they are gathered 
and validated, facts are asserted into the data base. Iri a situation with one firm and one 
department, there is no confusion since each piece of mf onratkiq appjes simultaneously to 
the firm and the dcpaiirnent But what happens if mere are two purchasing departments? 

When we investigate the departments of a f irm, we investigate their inventory 
characteristics. We may assert, for example, that Wad times of one are constant and the other 
are variable 

Later, when all defwrtments have been examined, we may look at facts concerning 
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toad titro onrer §H departments. We wouM like to toe* at en aggret^Uon of chijactmlstta 
over members of 'a set. In oor ewe, the Mt is the wt of pwthMtng dtpattmenu of the ftrm. 
The aggregation may be defined as a conjunction of «1! facts c*Kerning^he variability of 
item lead times. Alternatively, determine ectivitiei imy be provided for performing more 
spedattied ag greg ations. For example, t fact corweming tt» variability of lead times of a 
department may be included only If the department controls more than W ptroent of all items 
of the firm. 

We can implement these ideas by recognlrtng that there are two baric types of 
investigate activities in the questionnaire. We can investigate alt *M*f or a set of entities 
where entity U a firm, a department of i firm, or a purthaiing department of the f Irm. We 
may also investigate facts concerning these entities. We investigate, for example, the 
inventory characteristics of a specific purchajing department 

Entities can be organized into a trot or hierarchy that corresponds at a very 
aggregate level to the structure of the investigate tree. Because of this structure, it is possible 
to implement the questionnaire without passing variable*. In investigating a firm, 
PROCTdft first identifies the firm. Atl facts that ire dete i mined durtag the investigate 
the firm activity are assumed to refer to this firm anlen weexpHtitly reference a fact 
concerning another entity. 

While investigating thrfirm, we may investigate a purchasing department All 
fact* determined wfthlii this activity apply to thai department. When we complete the 
Investigation of the department, we again use tb* firm at the default entity. At the firm 
level, we may reference facts concerning each of its departments. 

In the implementation, I comidered the cue with one firm and one purchasing 
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department. I did not investigate notions of aggregation with respect to several departments. 
I did, however, implement the basic mechanisms for handling entities. Entities prove useful 
in providing a structure for organizing facts in the data base and in simplifying the 
dumping of the data base. 



CHAPTER 6 
m>LIMEHTATK) N Of THE MODEL 

This chapter describes the technical detail! of the implementation of 
PROCTOR in OWL. Readers unfamiliar with OWL are referred to the article by 
Hawkinson for a description of the implementation of OWL in USP and for a summary of 
the terminology that we use in this chapter. 

5.1 Overview of The Implementation 

Conceptually, PROCTOR investigates a firm by making a top-down toft-right 
traversal of a tree such as that in figure 5Ja. Illustrated U the tree for determining the 
status of emergency lead time restrictions. This tree is not prestored explicitly in the OWL 
data base the tree varies dynamically according to what PROCTOR knows. Figure Sib. 
for example, shows the tree as it would appear if the status of emergency toad times and the 
status of emergency lead tune price increases were known. 

The tree grows when a procedure for an activity is selected. For a consider or 
investigate activity, the procedure is simply a list of activities to be executed. These activities 
become sons of the original activity. For a determine activity, we may have several methods 
to be tried. These methods have activities which become sons of the determine activity. The 
lowest level activities are ask and assert; they form the leaves of the tree. 
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Determine tht status of emergency lead time restrictions. 

Determine the status of emergency teed timet. 
Ask the status of emergency lead times. 
Assert the response to askinf the status eTetnergency lead times. 

Determine the status of emergency lead time quantity restrictions. 
Ask the status of emergency lead time quantity restrictions. 
Assert the response to asking Che status of emergency lead time quantity 
restrictions. 

Determine the status of emergency lead time price increases. 
Ask the status of emergency lead time price increases. 
Assert the response to asking the status of enwgency lea4 time price UKreeset. 

Assert that emergency lead time restrictions are present 

A Portion of the Execution Tree 
Figure 5Ja 



Determine the status of emergency lead time resticttons. 



Determine the status of emergency lead time quantity restriction*. 
Ask "Om status of emergency lead time quantity restrictions. 
Assert the response to asking the status of emergency lead time quantity 
restrictions. 

Assert that emergency lead time restrictions are present 



The Execution Tree for a Different Situation 
Figure 5Jb 
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5.1.1 Two Modes of Operation 

PROCTOR has two modes of operation: toplevel mode and analysis mode. 
The toplevel cycle is trivial: PROCTOR repeatedly asks the user for a request. In toplevel 
mode, the user may request that PROCTOR dump the data base, change answers, print 
evaluations, or enter analysis mode to start or continue the investigation of a firm. Analysis 
mode can at any time be interrupted for a return to toplevel. Figure 5.2 presents a flowchart 
which shows the basic cycle of PROCTOR in analysis mode. 

5.1.2 The Basic Execution Cycle 

At the beginning of its cycle, PROCTOR selects an activity for execution from 
an event tree. (For purposes of this overview, we will assume that the event tree is a stack.) 
Let us assume that the activity to be executed is the activity to determine the status of 
emergency lead time restrictions. Figure 5.3 gives an OWL representation of this activity. 
The English translation appears in figure 5.4. 

This activity has a prerequisite that must be satisfied before a procedure may be 
selected. The prerequisite states that the status of emergency lead times must have been 
determined: before a procedure is selected, it should have a legal value or be unknown. 
Suppose that the value of the status of emergency lead times is undetermined. PROCTOR 
will satisfy the prerequisite by making 

t (DETERMINE (STATUS (LEAD-TIMES EMERGENCY)))! 
the next activity. PROCTOR resumes execution of 

[(DETERMINE (STATUS (RESTRICTIONS (LEAD-TIMES EMERGENCY))))] 
once the status of emergency lead times is determined. 
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The Basic Execution Cycle of PROCTOR 
Figure 52 
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[(DETERMINE (STATUS (RESTRICTIONS (LEAD-TIMES EMERGENCY)))) 
PREREQUISITE: 

(HAVE-DETERMINED (STATUS (LEAD-TIMES EMERGENCY))) 

[(: (WHEN (STATUS (LEAD-TIMES EMERGENCY) ABSENT))) 
CMETHODs (ASSERT 'ASSENT© 

[(: (WHEN (STATUS (LEAD-TIMES EMERGENCY) PRESENT))) 
[METHOD.IU8SERT fRESENT) 
■ (Hi ^@Rft" = •"•■• 

(STATUS (QUANTITY-RESTRICTION 

(LEAD-T4MES EMERGENCY)) PRESENT) 
(STATUS (PRIC¥INCR)EASE 

aSAD-ffMES^tMERGENCY)) PRESENT)))] 
[METHODS (ASSERT 'ABSENT) 
(IF (AND:= 

(STATUS (QUANTITY-RESTRICTION 

(LEAD-TIMES EMERGENCY)) ABSENT) 
(STATUS (PRICE-INCREASE 

(LEAD-TIM ES EMERGENCY)) ABSENT)))] 

EMETMaD^iASSERf %lNJK*!PWNJiD r 

[(: (WHEN (STATUS (LEAD-TIMES EMERGENCY) UNKNOWN))) 
[METHOD- (ASSERT 'UNKNOWNS!] 



Activity and Procedure* for Determining the Status of 
Emergtncy Lead Time Reftrtetiont 

Figure 55 
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Determine the status of emergency tad time restrictions: 

The prerequisite it that the status of emergency lead timet be determined. 

Determine the status of emergency lead time restrictions When emergency lead 
times are absent: 

Method: Assert that they are abstnt 

Determine the status of emergency lead time restrictions when emergency lead 
times are present: '--" ' m *" '*" v 

Method k Assert that they are present if emergency load time quantity 

restrfettainrire|iiU 

Method fc Assert that tfily are sbstnt if emergency lead time quantity 
restrictions are absent and emergency lead time price increases are absent 

Method S: Autrt that the status of emergency lead time quantity 
restrictions and th* statu* of emergency lead -mipuSk 1 increases is 
unknown. 



Determine the status of emergency lead time restrictions when the status of 
emergency lead «me»t» unknown. i--v#»*-- 

Method: Assert that the status U unknown. 



English Version of the Activity for Determining the Status 
of Emergency Lead time Restrictions 

Figure 5.4 



76 

Suppose now that emergency lead times are known to be present. The 

prerequisite is satisfied and PROCTOR can select a procedure. Procedures are activities 

that are specialized by a vh*n amdttton, a predicate concerning the type 1 facts that are in 

the prerequisite. PROCTOR selects 

t ( (DETERMINE (STATUS (RESTRICTIONS ULEAD-TIMES, EMERGENCY) ) ) ) 
(WHEN (STATUS (LEAO-TlfeS 'HfeNCVf PRESENT)))] 

as the procedure for determining the status of emergency lead time restrictions. 

PROCTOR fc now ready to execute. U updates, the event tree to show that a 
procedure has been selected and that execution, ha* started, and passes ,ti* procedure to an 
interpreter for determine activities. 

The determine interpreter executes methods of the procedure until one succeeds 
in asserting a value. Notice that a method may have an optional condition: a method is 
tried only if its associated condition it true. Notice also that it is possible that a fact in a 
condition might be undetermined. The determine Interpreter can suspend the execution of 
an activity to request that PROCTOR determine an undetermined fact <The event tree 
proves useful for saving the state of execution of the suspended procedure.) The determine 
interpreter continues execution once such a fact has been determined. 

Let us suppose that emergency lead time price restrictions are known to be 

present and that the status of emergency lead time quantity restrictions is unknown. 

[(IF (OR::: 

(STATUS (QUANTITY-RESTRICTION (LEAD-TIMES EMERGENCY)) PRESENT) 
(STATUS (PRICE-INCREASE (LEAO-TIMES EMERGENCY)) PRESENT)))) 

evaluates to TRUE and PRESENT is asserted as the value for the status of emergency lead 

time restrictions. The current environment and the appropriate direct dependencies are 
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recorded with this value. 

The event tree is updated to reflect the completion of the execution of the 
determine status of emergency lead time restrictions acflvAty and the cycle repeats. 

6.2 The Basic Representation for ActWtie* and Procedures 

PROCTOR's activities have the same liasic representation. Tiii* is iuustsated by 

the example of figure 5^ and the following exampJeu 

[(INVESTIGATE (CONSTRAINTS (DEPARTHENT PqBCHASJNG) ) ) 
OTETHOOi ■ — ■.-<*- 

(EXPLAIN (CATEGORIES AGGREGATION) ) 
(EXPLAIN tCONStNAtNtS JOlNT-OfiuWING)) 

(EXPLAIN (CONSIRAiMTS EXTERNAL)) - % 

(iNVESnCATE ((COtkTTRAIMTS EXTERNAL) tOEPARTWOlT PURCHASING)))]] 

[(DETERMINE (STATUS (RECORDS SALES))) 
DEPENDENCIES! NONE 
mETHODi (ASSERT (RESPONSE (ASK (STATUS (RECORDS SALES))))))] 

An activity may have optional prerequisite ind dependency attributes. The 

prerequisite is a conjunction of assertions that must be true before PROCTOR can select a 

procedure for the activity. The assertions specify that certain type 1 facts must either be 

determined or known. 

[(HAVE-OETERMINEO (STATUS (LEAD-TINES jqfajpgYi J U, 

for example, states that the status of emergency hid times must have * legal value or be 

unknown. We use HAYE-OETEROINED fof this example because * procedure exists to 

explicitly handle the case when the status of emergency lead tunes is unknown. An assertion 

can also specify that a fact must be known. In this case, the fact mutt have a legal value 
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before a procedure is selected. PROCTOR tries to satisfy the prerequisite predicate by 
determining the values of undetermined facts before selecting a procedure. 

The dependency attribute specifies an explicit environment for an activity. It is 
a conjunction of type 1 facts that can be used to create an environment to override the 
general environment mechanism described hi Chapter 4. PROCTOR determines the values 
of aff fids -to the expbdtehvmmiient before tt^xecuferan activity. Hi the above example, 
we state that the status of sales records has ho dependency. This fact does not have an 
explicit environment and does not inherit a general environment 

A procedure for the execution of an activity can be either the activity itself or a 
mhtn sptctaltzatton of the activity. In the example of figure 53, 

<mhe* fstttus ftM^f ms emmm pite^UTi 1 ) i 

Is a mhtn sptctaltzatton and 

[(uhen (statu* (teto-ftties emeAgency) present))] 

must be true for thU when spedtHzttlon to be selected. 

Each when specialization of ah activity as well as the activity itself can have a 
method. A when specialization i may inherit med^sa^ method details from its parent 
activity. Thus, for situations where only 1 or 2 when specializations need special methods, we 
define these when jpecitlinttkmi and let other discs use the method of the activity. An 
activity need not have any when specializations. 

tuNvesTtGidTE ccrjesfBiiffTS ctiEPwrrrathir nj^6«siNGn)i 

U both an activity and a procedure for the activity. Notice that ft is an error if a procedure 
with a method cannot be selected. 
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5J Data Structures Used by PROCTOR 

PROCTOR uses several data structural during Us execution. Thaw are the 
<v*nt tr«, the mttty trn, a set of tnotrmnunt ttm and a us*d+} lattiu. The event tree 
controls the execution cycle of PROCTOR; the entity tree organises facts in the data base 
and relates them to the firm and iti purchasing department; the environment tree and 
used-by lattice are used in the change answers procedure. AH structures are implemented in 
the OWL data base. 

5.SJ The Event Tree 

The event tree controls the execution of PROCTOR. Figure &Sa and 5£b show 
a portion of this tree as it might appear during the execution of the investigate constraints 
activity. (PROCTOR has Just determined the necessity and feasibility of a component to 
handle Joint ordering constraints. It U about to evaluate the type of component necessary to 
handle these interactions.) 

Each node of the tree corresponds to an event of the interpreter which hi turn 
corresponds to the execution of an activity. The tret i* doubly linked to make possible 
upwards and downward traversal without the use of auxiliary stacks. 

There is a continuation attribute associated with each node of the event tree. 
This attribute lis LIFO list of activities that must be executed before the completion of the 
event Activities are added to a continuation by PROCTOR to satisfy a prerequisite, by 
individual activities during their execution and by the change answers routine. 

PROCTOR maintains two pointers into the event tree. TOP-EVENT points to 
the topmost event of the tree. This event corresponds to the activity 



80 



[(event 10) 
calling-event* (event 8) 
ctltod-evenut: (event II) (event 12) 
activity* (investigate (constraints (department purchasing))) 
continuation! (e*pfcm {constraints external)) 

(mvestlgate ((eenstraints externalXdepartment purchasing)))] 

[(event II) 
calling-event! (event 10) 
activity! (explain (constraint! joint-ordering))] 

[(event 12) 
calling-event* (event 10) 
called-events! (event 13) 

activity!: (investigate ((constraints jc4m-ordermgXdepaitment purchasing))) 
continuation! (consider (aggregation family))] 

[(event 13) 
calling-event! (event 12) 

called-events! (event 14) (event 17) (event 20) (event 24) 
actlvityt:(eor»sider<co»«rairrtsJ(^if»^orderirlg))} 

[(event 14) 
calling-event! (event 13) 
activity! (determine (status (conttmintt Joint-ordering))) 

[(event 17) 
cafling-evenc! (event 13) 
activity! (determine (evaluation 

(neeesiity (l ystem com p onen t (handle (constraints Jo4m-ordefing)))))) 
procedure! ((determine (evaluation (necessity (syst et n -c wnp onent 
(handle (cawnraintt join t o rd erin g^ ) ) )) 
(when (status (constraints joint-ortering) present))) 
setection-vataest: (status ((eenitnUnu j oint oid o tof.) 

(((department purchasing) lX(f irm lXsession !)») present)] 



A Snapshot of the Event Tree 
Figure &5a 
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[(event 20) 
calling-event*: (event IS) 
activity*: (determine (evaluation 

(feasibility (system-component (handM) (constraints Joint-ordering)))))) 
procedure*: ((determine (evaluation 

(f eaiibMty (lyttem-component (handle (constraints joint-ordering)))))) 
(when (status (constraints Jofe*«dering) pretent))) 
selection-values*: (status ((constraints Joint-ordering) 

(((department purchasing) lX(f Irm lXsession 1)))) present)] 

[(event 24) 
calling-event*: (event IS) 
activity*: (determine (evaluation 

(type ( s y s tam-to m pu tt ent (handle (constratent Joint-ordering)))))) 
procedure*: ((determine (evaluation 

(type (system-component (handle (eonstraints Joint-ordering)))))) 
(when (statu* (constraints J oUrt - o i de r m g) present))) 
selection-values*: (status ((constraint! joint-ordering) 

^d ep artment purchasing) «(f bm lXse*»c« 1)))) present) 
continuation*: (method (d ets rmiin (evaluation (type (lysiem uanpun s n t 

(hanttit (constraintt Joint-or dering )))))))] 



Continuation of Figure BJa 
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[(event 8)] 



[(event 11)] 



[(event 10)] 




[(event 12)] 





[(event 13)] 


CURRENT-E 




^ / 


\ ^\ 


// 


[(event 14)] 


/ 

[(event 17)] 


[(event 20} 


[(event 24)] 



The Relationship Between Events in the Snapshot 
Figure 5.5b 
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t( INVESTIGATE (SESSION A))). The second ^t« 4* CU|ItENT^YENT Which 
points to the event that U currently being executed. 

The event tree is used primarily to sequence activities for execution. The 
activity to be executed next is always the first activity on the continuation of 
CURRENT-EVENT. Otherwise, if this continuation U empty, ft\is the tint activity on the 
continuation of the calling event The rule is applied recursively iwiUI PROCTOR reaches 
TOP-EVENT. PROCTOR timpty returns to the top feVetloop when there is no next 
activity. 'wv* /vr* 

The event tree is pruned whenever the execution of an event is complete. Thus, 
th* events finked bf dotted liner in figure 5.8b do not exist when we execute 
[(EVENT 24) ] . A saved event tree may have been useful, especiatly in the generation of 
explanations. We felt, however, that there ww too large an overhead in saving the complete 
tree. ThU deficiency can be overcome: the tree is easily recreated by recomputing 
appropriate parts of the session. ■'''■'* "' 

Each node of the event tree may have additional attributes. Selection-values u 
an "instantiated" assertion concerning the value of type 1 famtbat were used in the unction 
of a Pr ocedure for the ajctivity. ^section 5.m for a description of instantiation.) 
Selection-values are used in the determination of .environments. An event may abo have a 
dependency attribute that specifies the txpUdt environment for anactivity. 

5A2 The Entity Tree 

Entities are object in the uieifs werld. In the o^pnt imptonMntation, enUties 
and sets of entities can include sessions, a particular session* the firms of a aeaaion, a 
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particular firm of a msion, the departments of a firm, the purchasing departments of a firm 
and a particular purchasing department Thae tre represented In CFWLai 

[SESSION! 

((SESSION 1)] 

((FIRM (SESSION l))l 

t((FIR« If (SESSION 1))] 

((DEPARTMENT ((FIRM 1) (SESSION 1)))1 

(((fJEPAMMENT PUR(^NG?( (FIRM 1) (SESSION 1)))) 

((((DEPARTMENT PIWOKS^^ U))J 

Figure 5.6 shows the structure of a set of entities for a hypothetical data base. 

PROCTOR maintains a pointer (called C^RI^T-JENTITY) to a node in thU 
tree. CURRENT-ENTITY is the entity or *et of entities tha£ U currently under 
investigation. 

A new entity can be created whenever ^RQCTQR executes an Investigate entity 
activity. PROCTOR can be told to investigate jn. entity, to investigate &e entity, to 
investigate another entity or to investigate a set of entities. San$ examples are: 
((INVESTIGATE (FIRM A)) J 

mNVEsfiiMt 1fthm the) ) j 

[(INVESTIGATE (FIRfl ANOTHER))! 
CttNVESTlHrnl IfDEPWTMENT PIRfl))]. 

The new entity depends on both the CURRErfT-ENtltY and the investigate 
activity. Consider figure 5.6. For a CORRENT-EtftTTY of t(#IRM 1) (SESSION 11)1 
and an investigate activity of 

((INVESTIGATE ((DEPARTHENT PURCHASING) ANOTHER))], 
the new current entity will be 

((((DEPARTMENT PURCHASING) 3M (FIRM 1) (SESSION IM)1. 
CURRENT-ENTITY U set to 
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[(((DEPARTMENT PURCHASING) 2) ((FIRM 1) (SESSION 1)))] 
when the activity ((INVESTIGATE ( (DEPARTMENT PURCHASING) THE))] is executed. 
(We find the most recent purchasing department investigated.) 

[(INVESTIGATE ((DEPARTMENT PURCHASING) A))l indicates that PROCTOR 
should find the most recent purchasing department investigated or else create a new 
purchasing department entity. 

These ideas are easily extended. By specifying selectors such as all, each, first, 
second or previous, it is possible to implement investigate activities that investigate sets or 
that iterate through members of a set 

The CURRENT-ENTITY must be reset when an investigate entity activity 
completes execution. When PROCTOR creates a new entity, it place* attributes called 
previous-entity and new-entity on the event corresponding to the execution of the investigate 
entity activity. PROCTOR simply sets CURRENT*ENTITY to the value of the 
previous-entity attribute once execution of the investigate entity activity is complete The 
new-entity attribute U useful for resetting entities when PROCTOR travels down the event 
tree. 

53.2.1 Instantiations 

PROCTOR uses tnstanttatton to relate facts to entities in the data base. 
Consider the fact [(HUMBER ((DEPARTMENT PURCHASING) FIRM))!. This fact is 
instantiated to 

((NUMBER ((DEPARTMENT PURCHASING) ((FIRM 1) (SESSION 1))))] 
when CURRENT-ENTITY is [((FIRM 1) (SESSION 11)1. The instantiation of 
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[(STATUS (CONSTRAINTS JOINT-ORDERING))] is 



:*'*&*? 



[(STATUS ((CONSTRAINTS JOINT-ORDERING) 

■' -wtemmmwrtiMMfm) *)ftt^irif Session in >)n 

when CDRRENT-ENTfTY t» 

[((R3EPARTMENT PURCHASING) miFfMf it (SftSfOR 1))T1. 

The rules fwmstsjrttttton are fai^ 
of an entity X at any entity that appear* as a son of X iliHly tree. A suptrtntWfdt 
an entity X is any entity that appears as a father of X in the entity tree, This implies that 
(SESSION] is the superentity of all entities. 

The first example illustrates txpUctt tnstertUttm. Concepts that contain 

■'"', SESSION] ''''' '"-'- ••^^r-^rSiF r.i...-v 7 :--r.sey^ .■«■,.••: *■■•....,>■.?■.<.■. 

CCFIRrl SESSION)] 



[(DEPARTMENT FIRM] 

[((DEPARtMfti»iic^^ ! " 

[(DEPARTMENT PURCHASING) 1, 

are instantiated (depending on CURR*^-£NT1TY) to contain 

[(SESSION 1)1 

[(FIRM (SESSION 1))) 

[((FIRM 1) (SESSION X)ll 

I (DEPARTRENT f (FlRrT It (SESSION 1 ) ) ) J 



trrtOEPARtrlNT PURCHASlNlSr If ((Pit 
In making explicit InstantUtions, ther« are three ca*f* CU4\REKT-XNTITY can be a 
subentity of the class of entity that is nqutod; it can be aiuperenO^of the dau of entity 
that is required; or it can be of the correct class. In each casMbe enjttty U simply retrieved 
by searching the tree starting at CURR^T:ErfTT£Y. It U an «W»r.|f a>n **Wj of the 
correct class cannot be found. 
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The second instantiation example illustrate* (Ufauit tnstanttattim. A concept 
may have a DERIVED-ENTITY descriptor on it* reference list <or on the reference list of a 
generalize^. Such a concept is called a dtrtvtd tnttty. ([VENDORS! and I? TEAS] are 
examples.) PROCTOR specialties a derived entity by CURRENT-ENTITY when there are 
no Instantiations by either a subentity or lupereottty of j^RRE^r-ENTITY. Otherwise, 
PROCTOR uses the instantiation that already exists. .,,.. 

5.3.3 The Environment Tree 

The value of a fact depends on the environment in which that value was 

determined. An environment is represented by the concept ENVIROHMENTl f^jmHf^ by a 

conjunction of instantiated assertions concerning the values of facts that are contained in the 

environment Suppose, for example, that an environment contains the faos 

[(ACTIVITY FIRM)) and 

[(STATUS (CONSTRAINTS JOINT-C*DERING*)J, 

that apply to the entities 

[((FIRM 1) (SESSION l))land 

[ C ( (DEPARTMENT PURCHASING) I) ( (FIRM „JJ (SESSION 1) ) ) 1, 

and whose values are OTJRt^iNGrahd (PRESENTJ. This environment is represented by 

[(ENVIRONMENT 
(AND (ACTIVITY ffFlRfl t J (SESSION 1)) PURCHASING) 
(STATUS 

f(rJJNSTRi)irilTS JOTNT-ORftRTMG) 

(((DEPARTMENT PURCHASING) lHiTIflfl 1) (SESSION 1)))) 
PRESEUTT))! 

Note that the grouping AND U represented in OWL ai a concept whkh has an 

element property whose reference list contains the members of that grouping. In 



PROCTOR, we use the concept [(((AND X) V) Z)] to represent the grouping 

[(AND X Y Z)l. 

With this representation, OWL arranges env ir o nme n t* into a tree Suppose we 

had the environments, 

[(ENVIRONMENT X)], 
[(ENVIRONMENT (AND A B?)], 
[(ENVIRONMENT (AND AC))], 
[(ENVIRONMENT (AND A B C))] 
and [(ENVIRONMENT stAND A B 0))1. 

The OWL data base permits us to traverse these environments as if they were structured as 

the tree in figure 5.7, We take advantage of this representation whin determining the 

validity of environments in the change answers routine. 

An environment to easily derived from the event tree » ii a conjunction of thi 
selection-values attributes that appear on events in the path from CURRENT-EVENT to 
TOP-EVENT. An exception occurs when an event in this path has a dependency attribute. 
The environment for this case is a conjunction of the dependency attribute and all 
selection-value attributes that appear on events in the path from CURRENT-EVENT to the 
event with the first dependency attri b ute . 

Each environment is given a value of TRUE, FALSE or TO-BE-CHANGED. A 
newly created environment always has a value of TRUE. An environment is given a 
TO-BE-CHANGED or FALSE value when the value of a type 1 fact in that environment is to 
be changed or when the value has changed. 
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[(ENVIRONMENT A)] 



[(ENVIRONMENT (AND A B))] 



[(ENVIRONMENT (AND A C))3 



[(ENVIRONMENT (AND A B C))] 



[(ENVIRONMENT (AND A B D))] 



A Tree of Environments 
Figure 5.7 



&S.4 The Used-by Lattice 

Chapter 4 discussed the notion of the direct dependency of a fact on the facts 
that enter into m determination. In the implementation, we record these dependencies by 
giving each fact a value-used-by attribute. TT»« reference tot of the vafcie-uwd-by attribute 
of a fact hotdi all facts that have used the value of that fact 

The valiie-usfd-b.y attribute Imposes a partial ordering on facts in the data base. 
Fact A comes before facts B in this ordering If and poly If the value of fact A U used in thj 
determination of fact B. In other words, f act s B appear! on ^e reference list of the 
value-used-by attribute of fact A Notice that drcularitt* wmot exl* there U no feedback 
in PROCTOR; a fact A cannot depend on a fact B which in turn depend* on f act A. 

The used-by lattice is easily maintained by ineans oj^ | procedure called 
FIND-VALUE. FIND-VALUE places fact A in the value-used-by attribute of fee* B if the 
vahie of fact B is referenced in the determination of fact A 

5.4 Back to Basics 
5.4.1 Values 

In previous sections, we described elements of how PROCTOR maintains values 
in the data base. We wiH summariie the description in this section. 

PROCTOR maintains a distinction between values of fact* and values of 
responses to questions. The concept for 'value of the status of economies of transportation" 
for the entity [( ((DEPARTMENT PURCHASING) .l)i^^^(8t^|l«||. : l)JH is 
represented by the concept 
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[(VALUE (STATUS (ECONOniES-OF-TRANSPORTATION 

(((DEPARTMENT PURCHASING) 1) {(FIRM I) (SESSION 1J))1. 

The concept for "reiponie to the question concerning the statu* of economies of 

transportation" and i; f or the same entity U repreiented by 

[(RESPONSE (ASK (STATUS (EpcprtlES^-JTRANSPORTATiQII 
( ( (DEPARTMENT PURCHASING) 1) ( (FlNk mSESSfO^ 1) ) ) ] . 

The first position of the reference list of each of these concepts contains a value 
that can be one of UNDETERMINED. UNKNOWN or some legal value. A value of a fact is 
UWrrEftMNEB If there has been no attempt to determine its value. It is UNKNOWN if the 
user specified a response of UNKNOWN or if PKOCTO* can only assert a value of unknown 
due to lack of information. 

Each instantiated fact/response concept has a value-used-by attribute, an 
environment attribute and a creating-activity attribute. The value-used-by attribute has 
been explained in section SJ.4; the environment attribute contains the environment for the 
fact/response; the creating-activity attribute contains the activity that created the value. The 
creating-activity attribute provides quick access to the activity for the determination or 
asking of a fact 

The fact/response concept may also have a preliminary-value or 
preliminary-response attribute. These are unclassified attributes tot are used by the change 
routine for temporarily setting the vaku of » fact/rejponse to undetermined. 

8.4.1.1 FIND-VALUE and SET-VALUE 

FIND-VALUE and SET-VALUE are functions that maintain and provide 
access to values in the data base 
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FIND-VALUE takes a concept u an argument, instantiates that concept and 
returns the value of that concept The rule for FIND-VALUE is straightforward: if a 
prdiminary-value/preliminary-responje attribute exists, return its value; if no value exists, 
return UNDETERMINED; if a value exists but the environment hat a value of FALSE or 
TO-BE-CHANGED, return UNDETERMINED; otherwise return tht value FIND-VALUE 
updates the value-used-by attribute only if the returned vatic is "a tagal non-preliminary 
value 

SET-VALUE takes a concept and a vaktea* arguments, Instantiates the concept 
and correctly set its value SET-VALUE also "unsets* any preliminary-value, updates the 
creating-activity attribute, sets the environment and removes all references from the 
value-used-by attribute. SET-VALUE has another important effect: it recomputes all 
environments when it sets a value for a type 1 fact that has Just been changed. 

5.4.2 Evaluating Expressions 

In PROCTOR, expressions occur as conditions on methods of determine and 
check activities, as conditions in prtreeuUttw and wheir spedafixaUons, and as arguments of 
assertions in determine activities. The syntax for expressions is described by the BNF of 
figure M. 

Expressions are evaluated by recursively applying the rules of figure 5.9. Notice 
that an expression can evaluate to UNKNOWN or UNDETERMINED if data is UNKNOWN or 
UNDETERMINED. Notice abo that BE U different from EQUAL BE can compare a value to 
UNKNOWN without evaluating to UNKNOWN. 

MINIMUM, MAXIMUM and AVERAGE are both unary and n-ery operators. The 
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condition s- (IF predict*) | (UNLESS predicate) | OTHERWISE | 
OMEN predicate) 

predicate s» (AND predicate, predicate, . . . predicate,) | 

(OR predicate, predicate* . . . predicate,) | 

((BE value) feet) | (b«p wprcwion, a^nuiont) | 

(NOT prate**) | TRUE | FALSE 

expression s- (bop expression , expression^ | (uop expression) | 

v»iue|(iMpexpreukn, cxpiwkm t ...expfetftkm n )| 
fact 

bep s- GREATER-THAN | LESS-THAN | EQUAL 

bop =- QUOTIENT | DIFFERENCE 

nop s- TIMES | PLUS | MAXIMUM | MINI HUM | AVERAGE 

uop s- MAXIMUM (MINIMUM | AVERAGE | MINUS 

value s- integer | floating point number | range number | 'symbol 

fact =- an instantiated value fact | an instantiated response fact 

BNF for Expression* in PROCTOR 
Figure SJ 
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When x and v represent values of facts or constants, 
[(AND xy)) evaluates to 

(TRUE) ifx.[TRUE)/vy.[TRUE), 

FALSE) if x - fflSfel v 7 - FALSE), 

DJNDETERMINED] if (x - [UNDETERMINED] at* FALSE)) v 

OJNKNOUN] if (x - OJNKNOUN) a T * FALSE! At* UNDETERMINED)) v 
(x * FALSE] a x UNOETEfVltMBDl a?^ MMUMX 

[(OR xy)] evaluates to 

(TRUE) if x - (TRUE) v y - CTRUE1, 
FALSE] if x - FALSE! Ay- FALSE). 
OJNOETERMINEDJir^x * nicETeRHJNEO! a y * (TRUE!) v 
(x m [TRUE! a y - UNOETERMINEO)), 
OMKNQUNJ if (x - 04KN0UW a T * <TBUEja y>, {UUKTBWINEO]) v 
(x * CTRUEl a x m UNDETERMINED] a y - OJNKNOUN]). 

ttlF-xll evaluates to x. 
[(UHEN x)) evaluates to x. 

((UNLESS x)) evaluates to KNOT x)l. 
[(NOT x)) evaluates to 

(TRUE] if x - FALSE], 

FALSE) if x - (TRUE). 

[UNKNOWN] if x- OJNKNOUN], 

[UNDETERMINED] if x - UNDETERMINED). 

When op - bop | bep | nop, 
[(opxy)lis 

(UNDETERMINED] if x - [UNDETERMINED] v v - [UNDETERMINED], 
OJNKNOUN] if (x - [UNKNOWN] A y , (UNDETERMINED)) * """' 

t x (x* UNDETERHINEO) Ay- OJNKNOUN]), 

op(x,y) otherwise 

(((BE x) y)] is 

[UNDETERMINED] if x - OJNDETERHINEO] vy - [UNDETERMINED), 
x - y otherwise. 

[(uopxH is 

(UNOETERMINEO) if x - (UNDETERMINED], 
OJNKNOUN) if x - OJNKNOUN), 
uop(x) otherwise. 



Rules for Evaluating Expressions in PROCTOR 
Figure 8.9 
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unary version apptta only to rang t quantum which are values such at [<H3 , E4-B0] and 

[>108]. These mge quantities are rapraaitcd by the amcepu 

((QUANTITY UESS-THAN 11) H 
[(QUANTITY (BETWEEN (AND 24 58)))] 
((QUANTITY CGREATER-THAN 100))] 

The maximum of [<111 if 10, of (24-58] is tt and of [>18S] * 200. PROCTOR assumes 

a bound of twice the tower bound for "greater-then" ranges, file minimum of f>100] is 

101, of [24-50] is 24 and of [<111 it 0. Notice that quantities in range* are never negative 

The average of a range it timply the average of the maximum and minimum of that range. 
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M Extorting a Selected Procedure 

PROCTOR uses special interpreters to execute procedure! for each type of 
activity. The* are described In the following sections. 

5J5J The Ask Interpreter 

The following are examples of ask activities: 

t(ASK STATUS) 
{RESPONSES 

ftPEii YES-NO 

(TRANSLATIONji ABSENT PRESENTJll 

MARE THERE ECONOMIES OF TRANB*0RTa7hI| UHEN ySu ORDER 

ITE "s Fgon a given mm i^ fl W^AH^MW^ £> <WR 

ITEMS lU TRUCK LOADS fW CAR OJADTSIMlNmR fSPLACED?)) 

(TEXT [(ASK (NUMBER FAMILIES)) 
(RESPONSE* 
fYPEu SrNGLE-CHDICE 

(OPTIONSj ». 5XI H-St Sl-lff l»l-m.2|5l^ia >S88) 11 
' (HOW MANY FAMILIES OR GROUPS Of ITEMS ARE tri^Etf) 

Each ask procedure has a response attribute which forms the basis of its 

method. A response is described by a type attribute (description, yes-no, yes-no-value. 

single-choice, multiple-choice or value), a text attribute, and depending on the type, a syntax 

attribute, an options attribute and a translation attribute. The text attribute is created by the 

TEXT function which convert! a list of text into an Internal representation. (See section 

5.7.) Syntax, translation and options are defined as groupings. Syntax U an ordered list of 

predicates that are applied to a response to insure its syntactic correctness. Translation is an 

ordered list of values that are used to translate a yes-no or choice response. Options are 
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printed at the terminal for single and multiple choice responses. The options attribute can 
replace a translation attribute when a transltttbn field Is absent 

We make use of OWL'S ability to inherit properties when defining ask activities. 
t(ASK (STATUS ECONOfllES-OF-TRANSPORTATirjN))], for example, will borrow its type 
and translation attribute from CCASK STATUS)]. In general, missing attributes can be 
inherited from any generalization of a response. 

The ask interpreter checks the consistency of a syntactically, correct and translated 
response by calling the check interpreter. It eventually asserts the response by using 
SET-VALUE which correctly instantiates the fact and updates its environment 

The ask interpreter records the question number that is. assigned to a question. 
Each instantiated response concept has a quests* attribute on it* reference list 

There is also a ((QUESTION nil concept which contains the instanUated response concept 
on its reference list The ask interpreter is intelligent enough to know that a new question 
number should not be assigned to a previously isked question. If will not ask a question if 
the previous response to that question is still valid. 

5J3.2 The Investigate Interpreter 

A procedure for an investigate activity is an ordered list of determine, consider, 
explain and investigate activities. (See section 5.2 for an example). The investigate 
interpreter simply pushes the activities of its method on the continuation of the current event 
(in reverse order of course). PROCTOR executes these activities when i* continues its cycle. 



5A3 The Consider Interpreter 

A consider activity to a restricted vtr»too flf w toye^ftte KtJvUy. PROCTOR 
uses a common interpreter to execute both coruWer s^ kureitjfnte activities. 

5t6.4 The Determine Interpreter 

The folkming i* an e$ampte of a i 



[(DETERMINE (STATUS LONG-LEAO-TIHE-I TBS)) 
WETHODi 

- RrftSFitt • '"'•■■' 

(ASSERT •PRESENT) .. t 

(IF ;ttR* 5 (RfeffRSt tnSK (STAT&B lBi£UJunfcf Irus-I TENS) ) 

(SfAlSl^!^^ 
ISTEPii2 (ASSERT 'ABSENT), 

(IF (ANOr (f^rtHSE W#"is1lTttB iJB-tito-TIrlE-1 TEWS) 1 
AfSENT) 
ISWl^1r#aRTE^t1lBHB AttB^lfTlTl] 
ISTEPii3 (ASSERT 'UNKNjfMNjI 0^ 



Th« procedure for a determme activity "caii have one or more ewffafo. These 
are executed sequentially wrtfl a tnetbod »jcc**d» M fJswtinf f Value. (This is much Uke a 
USPCOND.) ft to an error V ho method succeed*. 

Each method may have one or more stops defined for tt. A single step method 
may omit the step in its repi eeai taUmi . Each nap to comitrtoned by an optional logical 
expression: HtF condtttaiTl, 1 (UNLESS mmtiW'WmiMfc: titl€RMISl mi« 
occur in the last ttepof a method and succeeds 




only if te eondlnw toewnfle* thto imptoithat more than one lip can be executed during 
the execution of a method. 
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Each step may have an activity and zero or more thin continuations which 
contain additional activities to be executed as part of a step. The activities of a determine 
are ask. determine, explain, say, comment and auert activitiet. Say simply prints text at the 
terminal; comment prints text at the terminal and stores the text with the fact for printing 
when the data base is dumped; assert asserts a value for the fact being determined. 

The determine interpreter makes full use of PROCTOR and the event tree 
when it executes a procedure. 

The determine interpreter first checks the current value of the fact to insure that 
It is invalid. It immediately returns to PROCTOR if a v*Ud value exists. Otherwise, the 
determine interpreter places each of the method* 9 f *be determine procedure on the 
continuation of the event for the determine activity and j*unu to PROCTOR. 

PROCTOR recognizes that methods are continuations of a determine activity 
and calU the (xmtinue^etennine mlerpr^ Th. 

eontlnue-determiM lnter|reter f li^a^ 

CURRENT-EVENt- ^^M**. *m**m>**m<> C o otiou . da ftwn toe wiH 
Umilarlly place the condition and activities of a «*p Jfl <ht continuation of *e event for the 
execution of that step. 

Jht contlnue-determlne interpreter ean evaluate expressions and modify the 
event tree U removes f£cw^t^4m*m^$* a ««* if the condition for ihat 
«*p fails. The ^twue^ttfminf interpreter mmm^mmmmmfl^th^^eni 
for the determine activity «|^ a method for that *|*^^^^ 

In evaluating an expression, it is possible that certain faeja^oe undetermined. 
Contlnue-determlne delays the evaluation of such an expression by placing determine 



101 

activities for each undetermined fact on the continuation in front of the expression. The 
expression is eventually evaluated with correctly determined facts. 

With thii approach to interpreting determine activities, the execution of a 
determine can be interrupted both to determine undetermined facts/responses and to return 
to toplevel mode 

5&5 The Explain Interpreter 

The explain interpreter is trivially implemented in PROCTOR. The explain 
procedure method contains a prompter and text attribute. The prompter U optional; it asks 
if the user wishes to see an explanation. The text attribute contains the text of the 
explanation. 

Explain concepts are loaded by an explanation function. The following is a 
typical example: 

(EXPLANATION 

[(EXPLAIN (DIFFERENCE (BETWEEN (AND DEMANDS SALES))))] 
*(. . . the prompter for the explanation . . .) 
'(. . . the text of the explanation .. .)) 
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5.5.6 The Check Interpreter 

The check activity has a representation that is similar to that of a determine 
activity. The difference is that a check activity may have nested steps in its method. The 
following is an example 



[(CHECK (AND (RESPONSE (ASK (STATUS (ITEMS SEASONAL)))) 

(RESPONSE (ASK (STATUS SEASONAL-INVENTORIES))))) 
OlETHOOt 
BSTEPttl 

(SAY "SEASONAL INVENTORIES CANNOT BE PRESENT 

IN THE ABSENCTOF SEASONAL ITERS.-) 
(IF (AN0t.it (RESPONSE (ASK (STATUS (ITERS, SEASONAL))) ABSENT) 
(RESPONSE (ASK (STATUS ^^ SEASONAL-lT^vllrORiES)) PRESENT) ))] 
[STEPtt2 

(SAY "YOU MUST HAVE SEASONAL INVENTORIES IF YOU HAVE 

SEASONAL ITERS.") 
(IF (ANDttt (RESPONSE (ASK (STATUS (ITERS SEASONAL) )) PRESENT) 
(RESPONSE (ASK (STATUS SEASONAL-INVENTORIES)) ABSENT)))]]) 



The check interpreter is ailed by the ask interpreter when the response to a 
question must be verified to be consistent and semantical^ correct The check interpreter 
first retrieves all check activities for a response there can be any number of activities to 
check a response against other responses. It then executes only those activities that have all 
responses determined. Note that check does not try to determine undetermined information. 

Check makes no use of PROCTOR in interpreting Its method. It merely 
evaluates the conditions of the steps until it either completes a method or until it reaches the 
deepest step. When check reaches an inner step, it has detected an error. Check then either 
uses the condition on that step to generate an explanation to the user or else it uses a text 
segment to print an explanation for the user. 



f^— &#^H«H^y 
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There arc two methods of recovery for a check error. The current question may 
simply be reasked, or the user may request that one or more of the facts that appear in the 
definition of the check be reasked. Check returns control to the ask interpreter if the current 
response is the only response to be changed. Otherwise, it executes the remaining check 
activities and eventually passes control to the change answers routine 

5.6 The Change Routine 

There are three components to the procedure for changing answers: the user is 
first asked to specify the responses he wishes to change; these responses are exploded to find 
all facts that are directly affected by the changes; a type 1 or type 3 change procedure is 
then executed. 

5&1 Accepting Change Requests from the User 

The user specifies answers to be changed by stating the question numbers for 
these responses. PROCTOR converts these numbers into the equivalent instantiated 
response concepts. The user can specify changes in any order, he may interrupt the change 
routine at any tune. Note, however, that he may not continue the analysis until all changes 
have been processed. PROCTOR can forget changes if requested by the user. Here, the 
preUminary-value/preliminarT-reipooie attributes become important In processing a change, 
PROCTOR simply sea a preliminary response to undeter min ed; it does not change the 
actual value of a response. PROCTOR is thus able to "unset" any change upon request. 
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5.6.2 Exploding the Direct Dependencie* 

PROCTOR uses a queue to find all facts Chat are directly affected by the 
requested changes. The requested changes are first placed in this queue. PROCTOR then 
processes each element of the queue by inspecting the next fact in the queue, checking to see 
if it has been processed and if not, by placing all unprocessed facts on the value-used-by 
attribute of that fact at the end of the queue. The process eventually terminates. 
PROCTOR sets the preliminary value of each processed fact to undetermined. 

A problem arises when incomplete determine activities have referenced f acts that 
are to be changed, (the user can interrupt a question and hence the determination of a fact 
These partially determined facts may have used the values of facts that are to be changed) 
PROCTOR is careful not to include incompletely determined facts in the explosions. The 
type I and type 2 routines take appropriate action to handle incomplete determine activities. 

In exploding the changes, PROCTOR must determine if any type I facts have 
been affected by the change, (type 1 and type 2 facts are distinguished by descriptors on 
their reference list or oh the reference list of one of their generalizations.) PROCTOR will 
execute the type 1 change routine if one or more type 1 facts have been affected. Otherwise, 
it uses the type 2 routine 

5.6.3 The Type 1 Change Procedure 

The type 1 change procedure is conceptually very simple. The values of all 
environments are first recomputed. This is easily done by taking advantage of the tree-like 
structure of the environment concepts. Each environment with an undetermined fact is 
given a value of TO-BE-CHANGED. The change routine then erases the current state of the 



a<* f ■"""** **' : 
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event tree and sets the continuation of TOP-EVENT to contain the activity 
[(INVESTIGATE (FIRM THE))]. 

As PROCTOR recomputes the session, It recomputes the values of all facts that 
are undetermined. In recomputing, it may determine new facts. SET- VALUE resets 
environment* as facts and responses are redetermined. Notice that with this scheme, all fags 
that were invalidated by a change in an environment can automatically be made valid if a 
type 1 fact is reset to its original value. 

M.4 The Type t Change Procedure 

The type 2 change procedure does not force a ro^tew of the entire session, "f'tijbl 
routine simply alters the event tree so that changedrype 2 facts 'wf^ be reevaluated. ^TJ* 
change procedure first does a topological sort of alt exploded type 2 facts. <Knuth 68> (TJw 
used-by lattice provides the comparison criteria for sorting these facta) The order of the 
facts in the sorted output specifies the order for the redetermination of the changed type % 
facts. 

The change routine creates a new event for each fact that if Jftht redetermined 
and makes these events the sons of TOP-EVENT, ft sets the attributes of theae •yents so 
that PROCTOR can correctly simulate the original execution. The activity attribute is 
obtained from the creating-activity attribute of die instantiate fas; the seiectfon-value 
attribute i» set to the environment attribute of tf^fag; ttw procedure for the activity is 
obtained by calling the procedure selection routine. (Remember that type 1 factt have not 
been changed. PROCTOR will therefore select the procedure that was used in the previous 
determination.) A current entity can be easily obtained from the instantiated fact. The 
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procedure- sets new-entity and previous entity attributes appropriately. 

PROCTOR places first CURRENT-EVENT and then the newly created events 
on the continuation of TOP-EVENT and sets CURRENT-EVENT to TOP-EVENT. 
When PROCTOR executes, it recognizes events on continuations and is able to bypass the 
procedure selection routine. PROCTOR will "execute" each of the events and hence, 
redetermine their values. Notice that all facts are redetermined in their original 
environment PROCTOR continues normal execution at the deepest node of the event tree 
once all changes have been processed. 

We have mentioned that interrupted determine activities pose a problem. The 
change routine erases the events for these activities and resets the continuations of their 
calling events before it processes the changes. These determines are subsequently correctly 
restarted. 

5.7 Printing English 

PROCTOR prints English from prestored text and by generating simple 
sentences from OWL concept structure. Text is stored as either LISP -TEXT or OUL-TEXT. 
The speciatizer of a LISP-TEXT concept U an index to an array that contains stored lists of 
text (This array is loaded by the TEXT and EXPLANATION functions.) the specializer 
of OUL-TEXT is an OWL symbol (a string) that can be easily printed at the terminal. 
OUL-TEXT appears in say and comment activities. 
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6.7.1 Generating English 

PROCTOR uses mutually recursive "generation <aga%"M convert concepts to 
text Each class of concept has, on its reference Ust or on the reference list of one of Us 
generalizations, a descriptor that names the appropriate expert to be used in English 
generation. 

PROCTOR has expert* to handle concepts such as groupings, B£ predicates, 
PROPERTY concepts, EVALUATION concepts and others. The BE expert will convert 



C( (BE PRESENT) 

«WfUB ffCfJNSTR*TNt8 EXTERNAL) 

(( (DEPARTMENT PURCHASING) 1) ((F|JW 1) iSESSJOJUl )))))! 



to There are external constraint* in the purchasing department". It passes the con^t to the 

BE-STATUS expert who outputs There are" since the value of the status if PRESENT and 

since [(CONSTRAINTS EXTERNAL)] is plural. ((CONSTRAINTS) has a (PLURAL) descriptor 

on its reference list) The BE-STATUS expert passes 

[(STATUS ((CONSTRAINTS EXTERNAL) 

( (DEPARTMENT PURCHASING) ((FIRM 1) (SESSION 1)))))] 

to the STATUS expert who prints "external constraints in the purchasing department". The 

STATUS expert uses the ENTITY expert to correctly identify the purchasing department 

entity. (The purchasing department may have a name that should be printed instead.) 

A concept can have a descriptor of class PRINT-SYMBOL on its reference Ust 

The speciaiizer of this descriptor is an OWL symbol that can override the general print 

mechanism for that concept 
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5.7.2 Generating Reasons tnd Evaluations 

PROCTOR generate! statements and reasons for each evaluation that it makes. 
The reason for an evaluation ii limply the condition of the step that asserted the evaluation. 
Or, if this condition is absent, it Is the selection value for the determine procedure. 
Evaluations are elaborated by using say and comment activities. 

PROCTOR takes advantage of the entity tree structure when it generates 
dumps Of the problem and the associated evaluations. As it traverses the tree in a 
breadth-first manner, PROCTOR lists all relevant Jaf orroatfon lor each entity encountered. 
This simple mechanism jives PROCTOR the ability to create 'semi-organized" dumps of 
the data bale. "" 



CHAPTER 6 

wmmi w gawmm 

The growing need for experts in areas such as law, medicine and management 
has motivated research in expert syrtem* <Gorry 74>. There are programs that are expert in 
legal issues such as the distinction between assault and battery cases <Meklman 78>, program* 
that can prescribe medicines for various bacterial litfectipn* <$hprtlifi e 7t>. and system* that 
can automatically generate data processing software <R||th TJ^. , ; TJie*e njrofra^i, are 
designed as tools assist to experts and non-experts in the soKitton of proWems f or specific 
domains. They are meant to supplement expertise rather than to replace iL 

The success of these system* motivated us to tacXlt * problem In Operation* 
Management It wu first necessary to select a subdomain of managable size .before any 
reasonable attempt could be made The domain of Operations Management was pruned to 
the subdomain of procurement, and this in turn was pruned to the area of planning and 
control systems for procurement From the variety of possible methodologies, we chose a 
specific approach: the hierarchical approach f or planning and control advocated by Hax 
and Meal Our research lead to the development of PROCTOR, an expert in hierarchical 
planning and control systems. PROCTOR does not replace the system analyst or manager, 
it assists the analyst by providing him with a formalism far exploring issues relevant to the 
design of a hierarchical planning and control *)»tem for procurement 
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6.1 Relation to Other Work 

Since much of our wcrk Km been in flu en c e d b y research in expert systems, it is 
interesting to relate PROCTOR to current research with respect to both computer science 
and management issues. 

There ire ^similarities between PROCTOR and medical expert programs such as 
MYCIN, a program that prescribes medicine for bacterial infections <Shortttffe 74>, and the 
Digitalis Therapy Advisor, a program that can suggest appropriate doses of digitalis for 
treatment of heart conditton*. <StWernun 74> 

MYCIN to rule bated . It $t»m with » go»l (identify in infection »nd procribe » 
medicine) and applies rules until it finds a solution. These rates are categorized into groups 
iccorftng how they ntUfy prerequtstttt to ^ MYCIN selects 

rotes by searching a Planner-like goal tree to find a rule that can derive information with 
minimal user questtonntng. 

This control uructure is limilar to PROCTOR's but only at the level of 
determine activities. PROCTOR has rules (when spedafcatibns) for determining facts 
concerning the firm. PROCTOR differs from MYCIN in that PROCTOR'S rules are 
much more structured and that only one rule is appropriate in any determination. (MYCIN 
might have several acceptable alternative! at any point in the analysis.) DOCTOR also 
differs m ov*r»H org»«itation. PROCTOR follows a plan when inventing the firm 
while MYCIN ii entirely ruled4Jased. PROCTOR strays fWmAis plaii only when it needs 
undetermined information; PROCTOR always returns to the plan. 

In this respect, PROCTOR bears a certain similarity to the Digitalis Therapy 
Advisor. The Digitalis Therapy Advisor is controlled by a Therapy Transition Network 
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(TTNET). Each node of the TTfET has subgosis m he staled, and in *atUf ying these 
goals, the program exhibit! its behavior. Nodes s/e jtfrwjged according to priorities that 
depend on the inf onnation known- to the progrup. Tto.^ttem selects nodes according to 
these priorities to determine what | must do next PROCTOR* activities are structured in 
a manner that Is similar to the T^iET. The coitfiw^t^flf the evem tree are subfpals 
that must be executed for PROCTOR to proceed Jn flriecUng the gosh, PROCTOR uses 
the priorities that arc implicit in the. ordering of oodsson the continuation. 

Our work can be related to current research lq/owi«emenl expert *y»t«iu, The 
Automatic Programming Croup at) «*, Laboratory Xol Computer Science (formerljr Project 
MAC) at MIT has been developing in Mil»rr»tk programming system called Protoiyitem 
<Ruth 75?, From a high level aa^tfh^tfan. of reeuireioentt for, a data proceuing system. 
Protnsystem can generate a -*U-dju| procewir* program aiid the JCL r-cemry to run that 
program on an IRM machine. Pptosysfem requires aivappMcaMon expert, an interface 
between the problem domain and l^feea^ae* f^oeratiy. Tk^ «weft^cou]d a«i« a user in 
determining his requirement* and thus in writing specif ication* for Protosystem. 
PROCTOR may be suited to this application. It a«4i*U><b« user in defining his 
requirements by evaluating components for an spplio^ons system. PROCTQ^^ output 
could drive a more detailed questionnaire that resolves issues of implementation and that 
determines the user's requirements in terms of data handling capability and report 
generation. ^ 

Some work has recently b«n done to providing computers with natural 
language understanding. This research, though not diiactlyeejatefi J© PROCTOR, ^ very, 
important for PROCTOR-tike systems. A deficiency of PROCTOR is its lack of an 
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explanation capability: PROCTOR can dump a data ban to provide a semi-organized 
description of the probtenvand its evaluations, but It carmot accept questions from the user 
and relate its evaluations to the user's model of the world. MaJhott* hat done experimental 
work in def ming the requirement! for an English Interface to a nwwgement expert system. 
<Mamotra 75> He has classified the kinds of questionrihatlmarn^^ nas stated the 
requirement* for a system to answer these queitioni. Rewarch has alto been done ill 
providing a computer with models for management problem solving. <Krumland 7S> 
Krumland's system usei^smalf gemAlii^ » dialogue 

with the manager. The issues of representation for the models and the dialogue are 
important for providing a management system with an explanation capability. 

A project that is similar in goals but different in approach is Mark's 
reformulation model of expertise. <Mark 7*> MrtYpNtiMAlfa&to-to&h description 
of a simple inventory problem and tries to solve that proWem by understanding ft in terms 
of a model based on* theory of consuWng. PROCTOR differs from Mirk's system lit that 
PROCTOR handles a much fcrger problem area but nor at the same level of understanding. 
Mark gives hU system a deep understanding of a smalt wethdef ined problem domain: his 
irstem solves sn«H pfobtem aivi m*v« them very well 

8.2 Further Research 

This thesis has only begun to explore the issues relevant to an implementation 
of an expert for a wbdomain of Operations Management PROCTOR tan be extended in 
a variety of directions both in the short and the long term: 
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6.2.1 Short Tarn Research Areas 

Research must be done in extending PROCTOR't dala ba*e: are** of the data 
base are incomplete; many of our evaluations are superficial. (It is encouraging that 
PROCTOR can display acceptable interaction* with tvfji * partially complete data base.) 
The data base must eventually be tested "in the fiefcl" to insure Us accuracy with respect J© 
both methodology and the way experts actually analyze problem*. 

In implementing PROCTOR, we did not make fuu g« of the OWL formalism. 
In generating English, for example, we did not make use of current ideas in English 
representation in OWL Bill Swartout U currently implementing the Digitalis Therapy 
Advisor in the OWL interpreter. <Swartout %> He hopes to provide the Digitalis Therapy 
Advisor with good explanation capabilities by taking full advantage of the OWL formalism. 
A similar project for PROCTOR might prove interesting. 

PROCTOR lacks a wen-developed notion of tiro*, ft knows that fact A came 
before fact B if B depends on A but It does not know when f ac| A , was determined. It 
would be interesting to consider how time would improve the efficiency of the change 
routines. In changing type 1 answers, PROCTOR currently reviews the session from the 
beginning to determine what information needs to be changed. With a notion of time, it 
might not have to review investigation* into joint ordering interactions when, for example, 
the status of vendor tradeoff s has been changed. 
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65.2 Long Term Research Are** 

There ii no ttrntt to research to extending the usefulness of a PROCTOR-like 
system. 

PROCTOR could assess the cost-benefits of implementing a planning and 
control system for procurement A maniger, for example, often need* answers to questions 
like "What if I don't include this feature?" or "How much does lead time forecasting buy me 
and how much will it cosffV Research is required in defining methods for making such 
analyses. 

Related to research in costs benefits analyses is the need to continue research in 
Operations Management methodology. Operations management techniques must be better 
formalized before a system can hope to provide expert evaluations. 

PROCTOR could eventually be linked to an automatic programming system 
like Protbsystem. PROCTO& could provide a first cut at a feasibility analysis: cost benefits 
experts could evaluate the impact at the Operations Management level of selecting different 
configurations; automatic programming experts could tackle issues related to data and report 
requirements. These experts could interact in the design and implementation of a planning 
and control system. 

6.3 Conclusions 

In this thesis, we have explored a subdomain of Operations Management We 
implemented a program that assists the manager in exploring the issues that are relevant to 
an evaluation of the applicability of a hierarchical planning and control system for 
procurement. This thesis shows that such a system is feasible for the domain of 
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procurement 

The ideas of this thesis can probably be applied to the more general domain of 
production and inventory control systems. Whether our asujfcs are can be applied to other 
domains is an open issue. The applicability to non-Operations Management domains of 
ideas such as th« categorization of facts for cbsnfiftf answers, the en Wronraent tree and the 
notion of direct dependencies certainly merto further exploration. 
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APPENDIX A 
SAMPLE SESSIONS WITH PROCTOR 



TU$ mppmilm eemeim i— ml am w t a t a a' md— mkk PROCTOR. TU 

••••^•■Biwy- Miiiniii •••'"'"■" 

Today it April 27, 1976. 
The time is 7:25 pm. 

Wwtiryoli»fiii%tHlgf-- - 

(Please anter your name followed by a return) 

(Entor here* Mr. Adam Smith 

And what do your wAnaw^dryouf 

(Pleaee enter your name followed by a raturi*} * 

(Entar hero): Mr. Smith . . ■ - v 

TTuir* ywifMr. SiWBt ' - — " fc " : — ■"-"- 

This questionnaire is daaifnad to halp you identify tne gonerst characteristic* of a 
planning and control system to support d**k>r* m th. area HprocurOfaarrt. _ . 

Do you naad information concerning tha oparation of thia ouaatloroaka? 
Pleas* follow your answer with • return, jtt . ■ . 

(Please key in yes or no): yes 

This is a short nota concarninf tha ua* of tha questionnaire. 

Tha questionnaire has two mods* of oparetiara ansfyela mode and toplevel modo. In 
analysis moda, wa invastigata your firm. In toplevel moda {which 
requost changas to your responses and Hstings of useful Won 
wo will mova f rooty between toplaval moda and analysis moda. ^ } ^ 

Whan you type in a response, follow it wjtj 
multiple choica, antar your choices saparatad by Hants 
If a quaation require* Rip of text as input, follow each 
whan finished eriter or, aMonal cartage return. ^ 

If you are uncertain about s response, Mjy In I If you do neiysia 

of your firm, the questionnaire will try to proceed without tha Irrformatioa At toplaval, you wW 
normally gat an explanation. 





carriage return and 



You may interrupt analysis moda at m^MhSt 
toplaval. Kay in T? to have the current question repeated. If 
just key in help as tha response to any question. 

Ok, let's begin. 

And Mr. Smith, you are at top level. Please sated one of the 

lqdt 







you to 



-**l; 
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2 start an analysis 

3 help 

(Enter bars): £ 

(1) Mr. Smith, whet it the heme of your firm! Use « many Bnss ss you need, following each lino 
with a carriago roturn (er). Finish by Ntttng an extra (er)t If you novo no answer, JMst hit (sr). 
Ross* bogin _ 

KBS Foods Ltd 

(2) What is tha addrass of KBS Foods Ltd? Usa ss many Nnos as you need, following oach lino 
with a carriago roturn (er)t Finish by hitting an axtra (cri U you hove no^ pjey aj r , Mut ,*•($ fffK 
Ploasa bogin ~. ...-_,• 

Cambridge MA 02146 

Now would you like an explanation of tha alamants of a general pre^uct structure that can be 
used to define tha major adivltias of KBS Foods Urt? 
(Plosso toy in yes or no): yas 

One of the basic issues that determines tha general characteristics of a planning 
and control system to support decisions m tha area of p u r chasing end production management 
la the natura of tha product structure ofths fjrm, ot h ,,- mt: . , h n <.*h.™& ■■;*■■ ', &■" 

An Illustration Of a felrry t^nst si produd structure can be represented aa follows: 

supplier a ''' . ., e 



roM eeintenence 

■atari els toola auppliea parts 

rou eater io I inventory 

component ports 

!: '" ; ^ptref^iid- parti" '" 
-fabricated porta 

per te wiorK-1 h^pJhOceea I nventory 
-purchased subasseObllss 
-fabricated «jbesM**r les 

subesseebly Mprk-ln-prQceai 



purchesing 



production 

( inter ejttenjt 

,. arid. .. -,, c , 
continuous 

bperitidhe) 



finished products 
-purchoeed f Jnl 

£s^^¥uV.fdj 



prodyct|i 



finished product inventory 

distribution process 
-distribution centers 
-werehouses 
-uholeeelers 



distribution 
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-retai I era 

The various elements of the product structure define three major functions: 
purchasing, production, and distribution. 

Obviously not every firm possesses every element of the general product 
structure presented above. Retail or wholesale firms are engaged In purchasing activities alone. 
Many production plants are not involved in distribution operations. 

As noticed in the above product structure, the production function (which 
trensforms raw materials into finished products) can encompass two major types of operation: 
intermittent and continuous. It is useful to distinguish between intermittent end continuous 
activities since the manufacturing characteristics and the managerial decision, associated with 
these two processes are quite different, the following table provides a gross comparison 
between these two types of operations. 

type of process 

character iatica intermittent continuous 

process configuration job shop asserts I u line 

locus of decision decentralized centralized 

mak i ng 

equipment flexible specialized 

lat >° r high skilled low skilled 

echeduling dispatching permanent design 

The following questions classify KBS Foods according to tit activities, eeemU organization 
and site. The current version of PROCTOR can **J« handle « pur* procurement firm with one 
department and "many* items. PROCTOR mW tot Mr. Smith proceed only If KBS satisfies this 
description. 

(3) Mr. Smith, is KBS Foods Ltd a procurement firm with no distribution or production activities? 
(Please key in yes or no): yes 

(4) How meny purchasing depsrtments does KBS Foods Ltd have? 
(Reese key in s value): 1_ 

(5) Does your purchasing department handle more than a few (say 10) items? 
(Please key in yes or no): yes 

Zl??! * ftr,t *"*•«**««*•» i»*« erdering interactions and external constraints far kerne of 
KBS Foods ltd. 

PROCTOR offers a "canned" explanation concerning issues ef aggregation since Mr. Smith 
requests it. 

When dealing with purchasing decisions it is sometime* useful to aggregate 

individual items into groups of items for planning purposes. There are three categoriee of item 
aggregation: items, families, and product types. 

Do you need information with regard to the definition of these three categories? 
(Pleese key in yes or no): yes 

The following three cstegories of item aggregation will be used: 
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Items rater to the highest degree of specificity rsisrd»ng porcbsssd products. Items differ in 
terms of tnKhaairtf liftsrMteriiliCi ilte rt^ jkj&im***** «*?<?: ;■-••■ 

•wi ■■•• w» ipvvnewf ■ wi ien wvnn iviive| wswm •eHW| .iMMiewevespewPi jgfans. _ ,^ , 

Families of items sre groups of items thst should be ordered jointly to obtaJn econo mies of 
scale or te fac^ste <r» 0>ds# irtei se pr ccsit , Tt si ^ #r l>« y COflm^ w-dOrlrig cost should po 
tr**ed fn • fsmfty. -»• ^ • - ^'T' ;*~ * / 



Product types constitute ?f§n>§*ttonjf lton^^epdJNM»W|f« oK 
characteristics, such as* slnjnat demsno pottoi m.'Gntt coats, my 

IlfVmS. 




fyMljUer 



T*e '*nr% */ »<to ft tss »r lj| 4 ffo iM fWN | **$#»Ji tttetfSlhtml. 

And Mr. Smith, we wHI now attempt to identify wr»tr^Jhert e« toterscttom mKong your 
purchased items that warrant aggregation ofllfftf 'WrMml. 

Do you need information with regard Wttem Inteftctfenf 
(Please hey in yes or no); yes 

Whenever trmrOire no Interactions emordjlrfcllu^ibesed items, the cOntrdL, . 
procedures ere extremely simple, It junough to DrejsfMteflSttirements of each Indjyjfrej, 
Item during the procuramsffnlertmie^lhd to repfenjsjffPfpfej inventory in sppropriste 
economic quantities. ; ,^ , 



m.«jV'.- ?!?;;-*■' 




Jrm to^toj^Joeof , 



The jnost common interaction smoi 

Nvifi'1 ffil. Adv. 

rates, ^^M&ttmmm^ .of 

more complex control procedures, and was control on MfvMusI item service . Items 




?«v 



0Mstfon*6 thnmgk Id immdgmta At d>tww s/ I wttrsctfsni tesr margea* ,t*t j s fj i f d*y e fi »s ^ 

•f m mriuk * h*^ J4m •&mfk*mM[ ~' xr '""^ ^^^;*;;; '' ■/ * ^„, 

(6) Are there economies of transportation when you order items from s given vendor teju . 
would it be better WWder items irftfofefieeW if?!*! oYdfls placed)? 
(Please key in yet or no): n -'■■ ' * 

ftctfc* tfctt ***n Mr. Smith U**AU » «w«^ *»w*lfeA T^W^CM* »//*» en *%fA 

end ttat •xplfwt esmpis* srdsrt end mmJiMmk srd«r> wt fafc fn d feets ewwi ej^lilien 

ordering eoiijL PApCTOft mm kdtrmmkm torn p t sri s ei f end 9am«n k MjHferet KBPs v , 

■ eee^B'We wnmY^wweeaeve Wm^WP«^ ^^W w^e^P o^em^^ovhWt , . 

(7) Are rhsre etonwniesof «tetefrtf tsnfes c^s^ 
dkiw mey* win ■neres common oreermg cosrx 

(Pieese key in yes or noH ? '' NV; ! ' i -- :T!,G ^ ' ■-• ;; "«^ 

Do you need fofcffmitlolf'wJth regard to the components of the cost associated with issuing a 
purchasing order? 
(Please key in yes or nob y. 
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The purchasing ordering cost has two basic components. 

The first component is the direct cost involved in releasing an order. It is 
represented by the cost of the order forms, envelopes, checks, receiving forms, stamps, some 
portion of the supplies of the purchasing department, as well as expediting materials, telex, and 
telephones. 

The second component is represented by the salary of the personnel assigned to 
processing the order from its initial release to its final delivery. The following departments c«n 
be involved in the release of a purchasing order: purchasing, receiving end inspection, storage 
and warehousing, freight and traffic, accounts payable, machine accounting. 

Occasionally, when dealing with very complex vendor orders containing multiple 
items, it is important to distinguish between a cost per header, which is the major ordering cost 
(a fixed unit shared by elf the Hems in the order), and a cost per Hne which is a minor cost 
added to each line item. 

(8) Do you have complex vendor orders containing multiple items where costs per header and 
costs per line items have to be identified? 
(Please Key in yes or no): n 

19) Now Mr. Smith, is it common for you to order more than one item in a given purchase order? 
(Please Key in yes or no): yes 

(10) Are there quantity discounts that can be obtained by joint ordering of several items from a 
given vendor? 

(Please Key in yes or no): ? 

PROCTOR has identified at least one joint ordering interaction: common ordering costs in 
question 9. Notice that U can proceed even with an unknown response for question 10. 

Joint ordering support is possible if item* can be grouped into families for joint 
replenishment. 

(11) Are there groups of items (families) involved in joint ordering interactions that share 
similar unit costs, demand patterns purchasing lead timet? 

(Please Key in yes or no): yes 

Joint ordering support is necessary when a significant number of items are af footed by these 
interactions 

(12) Do you Know approximately, what percentage of your items do not belong to families and* 
therefore, can be replenished individually? 

(Please Key in a value): ? 

(13) Do you feel that economies resulting from taking advantage of these interactions are 
significant enough to warrant a special system? 

(Reese Key in yes or no): ? 

Mr. Smith could not answer questions 11 and 13. PROCTOR explains that it unable to aseess the 
necessity of joint ordering support. This explanation is generated from data that PROCTOR 
has determined and from the representation of its internal procedures. 

A decision concerning the necessity of a component to handle joint ordering constraints could 
not be made. The reasons for the decision are that 
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1 your judgement concerning the significance of )^ oVdirtn| constraints of the 
2m^iS^ TfL-1** ,c»)^ d-pert^ ja not known. 



'5«5s 



PftOefttft omwImw Mil /**&?** *iv«eti»* fe aoijofi •**» tee*** it 
<tfc 






A component to Hondo f 
r ine daemon is 



«« 




SMjW* 1 * Thereeeon 



;$1 



PROCTOR tries te centime fii tee l**»ort|*il*w. 



ejr iteeii •**" tee 



^^ <^i . .'"w^" -*""-. 5p» eee^p*; •* ■e^e eaeteema^jO/ iflmj^ajaew^i' ^li\m-&^&'***^**t 
m meny cWferert Item rt^^ SwI i i i ^^ ^ig ' 1 * 

Pleeee select one of the following: 

11*^ then 11 ,-•-'•■••. ' 

2 between 11 end 100 

3 between 101 end 800 

4 between 501 end lQQQ 

6 between 9001 end 10000 

JIMS 
9 more then 50000 






**. 



(Enter here): 6 

(IS) How many fimffies (group* ot item*) ere there? 

Ptees* select one i tir 



flee* thin 11 

2 between 11 and 50 

3 between 51 end 100 

4 between (01 and 250 
- m between 2»l end 900 

6 more than 500 

(Enter here): 2 

PROCTOR emtutoi prmewd amy Awtfcr. Te* jMrcsfrtajr* « 

det*reiew Mmmmf^fi^l^m&mJ^mmw 

/•Jet erdertef expeert. (PROCT0K wUl eefy mggtitf 
of item* ere i ow e fee*' te famUy mggrtgmthiO 







AMil*a*1ien concert** th* flasttottfty of a to fe hindt* jo< in the 

purcheaing eepeHment cOuW^rtb* mad*. Ifhte H :fi*y*Vth» eVaVaW juslfr of the f«»Jy "I 
items of the purcheaing derMftMtntii m~1bNm : iM§mm^mm^m% 
module for .Joint ordering constraint* couW net be made. ,.. ....... ;., .,-■■.:■■ ; '-«^ 



PJIOCTOft iriw an •ftaniato «tret*f je p«^|rt ITr. Smite «*W »• MtWbd «<tfc • f porting 
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preeeeVuv instead. Mr. Smkk i*eU*i f fate/met tkt iesatrtgeHan. 
(16) It is sometimes desirable to aggregate similar Hems Mo fiwllfar merer? for reporting 
purposes. Would you lilu^smiiy aggregation to bo considered for this reason? 
(Please key in yes or no): ! 

You, vo at top lovol. Roo^ soloct ono of tho foHow«o» 

iqutt . 

2 continue the analysis 

4 change answers 

5 summarize tho analysis 

(Enter hare); £ 

The following is a list Of possible summaries. 

Please select one or more of the following: 

1 print a summary of tho facts coHocted 

2 print a summary of tho recommendations so far 

3 print responses to questions 

(tntor'hiroh't ' .; ..:^ 

PROCTOR see mpply « mmmmry — ahetfaw at e*y aha* imHmg tlm JumH^mritm rAereeeV 

•fcaald wte tat tkU test fa wet p r a at ai sd at fa f ■owe ud fnm tofjfleeiioapt truetmr*. 

Date of session; April 27, 1976 
Time session staffed* *J» pm 

User's name: Mr. Adam Smith 

Tho following data is about the purchasing department 

that 

1 your judgement concerning the s£nificance of joint ordering constraints of the 
purchasing department Is not Known. . , .. 

*the percentage of npMamtty Homo of ths iHrcM^.itaejrN^ (• not known. 

A decision concerning tho feasibility of a component to handle joint ordering constraints could 

not be mode. The reason ■— "- -■—«-'— «-•»--» *•--■ ■— -- - « - -- 

purch W ir*d.p*dm^ hr 1 
handle joint ordering constraints 

A module for family aggregation is possible. This is because you decided that the 
family aggregation of the purchasing department is poaatbta. 

You are at top level. Please select one of the following: 

iquit 

2 continue the analysis 

3 help 
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4 change answers 

Biiinwwartisj tin analysis 

(Enter here): 4 

ThU $mUm iilnatretet tea feaarel mtchmnUm fmrekmngktg n mi u mi. Mr. Smith tpmciftmttkm 
mmtmmr km mmm seanf*** ay fsstef PROCTOR m •*•*<•« ao mfr ar. JNre ee reaeasft feat 
PROCTOR reeae quMtUm IB t mmt mmimg tea ifo^/fames a/ jee* *HJf»if i f! > r * c < **'"- 

The currant question numbers range from 1 to IS. Retet key in the numbers corr« 
questions whose answers you wish to change. 
(Please Key them in): 13 

So far the following will be changed: The response to question 13 about your judgement 
concerning the significance of joint ordering constraints of the | department. 

Do you went to change any more? • T ' : ' f "" !jy A " 1 *'*"-" " 

(Please key in yes or no): n 



Do you wish to delete any requestsT 
(Please key in yes or no): n 

PROCTOR comtUmmt by making Mr. Smith /er Ms asm i 

(13) Mr, Smith, do you feel that economies resulting from taking advantage of these interactions 

ere significant enough to werr ant a special system? , 

(Reasa kev in Ves Or ntt* vos ' ' ^ ,.,!,'* V 



. PROCTOR ehmngmt tea •mmumr without rmt»mpmti*g tea satire mtm^ Qmlxjnimjmmlimn* 
eomemmimg mmemattty aod /#aj*Wlliy«ra radawr arfii s d . Metis* test lie so a la a ti a n * a/ tea 
pouUMUy mf /entity mggrmgmtUnU ** rm iMrmimmi. PROOOR mf m^i thmt m ^m t iph U 
mmmimi with m nt ktmmUtg tea ea resniae * a/ Items thrnt ere ia ea f e aa' MjIM eir4en$Kf 

wvOef^^veeVrvef^rPe^Ps MW) mommo* ' a^^Fsv^p^^TF ^ev^^evme^ev^a wWQw9 JweeB^^ajf . 



A module for joint ordering constraints is needed. This is bacauM voujdacjdod |M the joint 

ordering constraints of thi portrjealngclepertment mi aknmcpntAo^cWon concerning the 

feeef^orV^mo^lofl*^ 

decision is that tbo average number of the fami^ items of tht purchasing department Is not 

known. * ■'•>.• ^ ' - .-"'.;.* -*••"?■ 

(16) It is sometimes desirable to aggregate similar items fotd famj|N> morejy porting 
purpose* ^buWyofiHfiifamlr^ 
(Please key in yes or no): ! 

JfrV 5inM te««rr«pt< PROCTOR. Rm >o ea e *> thrnt 'fasti If r lea ao ro a et aa* ?/ mm- 

/•emy* mHiv oe twmwttu 

You are at top level. Please select one of the following: 

lquit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 
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The current question numbers ring* from 1 to If. Ptoses l»y kvB» numbers corresponding to 
questions who«o answere you wish to change. ^ , ^w- 

(Please Kay thorn In): ^jg 

Do you want to change any more? 
(Pleas. Key in yes or no): n 

Do you wish to delete any requests? 
(Plaaaa Kay in ya« or no): n 

(12) Do you Know approximataiy, what percentage of your items do not bejoog to familia* and, 
tharafora, can ba rapianiahad mdhHAmltyr" ^ ' p ^ r ^ r ^<- 

(Please Kay in a valuah 30 

A»df« i*im •rd~<* t Ut *m «h n ». JM* titer WMgr ^jJ l K offijg Aejiijgaae 

*•*"•*• «*« »*• «•« /er toa data*!* a/ tfta m*4*U U >ia^ las* «ae>7«*Jfl# »(» i« 



A component to nantta joint ordering certstririntt is ' 
fimWy aU r ^rt Wi ^ pwrt a l a artd» r ' 
avaraga number stir* family tto 

the deliR* *f a itodutettr •JK#t ., 

oKparfanefc Jrtn r% rds*tnf i nr a r e cfl w ;* i,,, 

ba > M^ta io tf <nto fa^iaa. Tlli ro'k a ni < 

1 a compormnt to handla Joint ordw^ comtra|»rt« in tr». purchasing depertmant it 

2 joint ordaring constraint* ara prasant. 




(16) Now it Is sometimes daairaWa to sffrafata simHar itamt into faatfUa* merely to/ reporting 
purposos. Would you BKo f emHy aggregation to ba con s id er e d for this raaaont 
(Plaasa Koy in yos or no): | . T^ •■ 

You ara at top laval. Plaasa soloct ona of tha following: 

1 quit 

2 continue tha analysis 

A change answers 

5 summarize the analysis 

(Enter here): g, 

Now the following is a list of possible summaries. 
Ptaas. sefact on. or mors of tha foltowing: 
1 print a summary of tha facts collected 
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2 print a summary of tha racommandatlons so far 

3 print ratponaat to quaatteoa 

(Entar hara): 2 

Mr. Smith roaatasts that PWCTOR prim a mmmtry rtjttrt a/ naAajajMadaJiMis. J* JtOCTOJt 
prima oil otmlmmtUnt It mm mmU. 

Data of aaaaion: April 27, 1976 
Tima aaaaion startadt 7:25 pm 

Usar's nama: Mr. Adam Smith 

Tho following data lit about the purchasing dapartmaot 

A modulo for joint ordaring constraints ia n a ad a d TNa hi bacauao you dacidad 
that tha joint ordaring constralnfeQf tha ^i^m^iUmM^^M^,9i90imim. Am*****'-- 
joint ordering fedefgejt are. that 

l.comp* ^tt^^a^PoMiSISr^- . 

2 a componahtlo handle joint ordering constraints in tha purchasing dapartmont la 
n a a dad. , _._ ._,..,,. ,.,■■■ ^ '.■>■•■ 

9 fha average numbar tf the family items Of tha purchasing department ia mora than 20. 

Concarning tha details of a module f or jojnj prdar|n|.jcoj*^a^iJ,,lft|a^ that **perianca joint - 

lnto !*f^J^5W* jtfWwt 1» hjn^l^ocia^icpajatralfdi In tho 
purchasing dapartmant ia fo^ell ify JqW Qrdef^4^ra}ntt«a ejseejrt^the purehaetag 
department A comftf^ to"h^ ^ tha-dooWon 

ia- that you daddbd Yr^ fl^ «y a«Wtk>n oTtha p wiha al raj rt a parto ii nt la p oaai h ia . , - 

You ara at top (aval. Ptasaa aamct ona of tha foHOwing: 

1 quit 

2 continua tha analysis 

9'hoip " : 

4 changa answars 

5 summarizs tha analysis 

(Entar hara): 5 

Mr. Smith, tha following is a list of possibta summaries. 

Plaasa salact ona or mora of the following: 

1 print a summary of the facts collected 

2 print a summary of tha racommandations so far 

3 print roaponaaa to quastiona 

(Entar hara): 3 

Mr. Smith Um hit kmjmmm for qmrnttmu It **i 13 u immrttkmt ♦*• chm*#« hmv* kmmm mU* 

Tha currant quastion numbara ranga from 1 to 16. Now the following * a Hat of possible 
summaries of responses to questions. 
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Please select on* of the following: 

1 print • summary Of aN questions 

2 print selected qusetions ,< ws 

3 return to toptevei 

(Enter here): 2 

You can repeat the following options at many timaa at you daalro* ^ ;r 
Ploaao select ona of tha following: 

1 aalact questions in a range 

2 wl^t IndJvkhrtf qqa«tt6*» \ 

3 print thosa questions selected so f ar 

4 leave the selection loop 

(Enter here): £ sr-^.^ .■-,:> ,-. 

(Ploaaa toy In tha questions you wish Hatodh 12 13 

Da you wish to select more? 
(Ploaee hay in ya* or noh n 

Pioaaa salact ona of tha foHowinf: 

1 salact quastions in a ranga 

2 select individual questions 

3 print thoso q u es ti o ns selected so far 

4 leave tha salaction loop 

(Enter here): 3 ■'*'■■ ■ * '■ 

Question 12 

concerns ^percentage of non-family items of the purch^n, dspartm^ , 

Quaation 13 .■•-..,$*•* ..::;'-,•:-. 

purcnawng department 
rosponsat significant 

h*. Smith, you tun repeat tha Wf*rir« otfkmt as tear* W^ 
Pioaaa eattcfrono of ths f o Ub ai M : " w - "=-" 

1 salact quastions in a ranga 

2 salact Individual quasttons 
" 3pi^tr^q^a^ :l ^s<tadsofsr 

W1VV (NO WMBtfQff 10W 
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(Enter Kara): [ 

Now you ara at top lovol. Ploaso taiact ona of tha following: 

lquit 

2 continua tha analysis 

3holp 

4 changa answars 

5 summarito tha analysis 

(Entar harak i 

Mr. Smith i«eM«« ta mnw taa satalMi 8*4 la ea wrtwt a/Mr a «#//*a traat. 

Mr. Smith, do you raaHy want to quit? 
(Ptoaao toy in yas or noh yas 

Do you wish to savo what you havo dona so far? 
(Plaasa toy in yos or no): yas 

A rocord of this sosston win bo savod Mr. Smith, do want s litting of tho aoaaion submitted for 

printing? 

(Ploaso toy in yos or no)t q, 

Tkm rmtmrm •/ M r. Smkk. . . . 

Woteomo back Mr. Smith! 

Today is April 27, 1976. Tha tima is 7s38 pm. 

You aro continuing tha analysis started on April 27, 197$ at 7:25 pm. 
You aro at top lovol. Ploaso sated ona of tha following: 

1 quit ,-.*,,. . 

2 continuo tha analysis 
3halp 

4 changa answars 

(Entar haro): 2, 

PROCTOR ask$ t f Mr. Smith with** fcmUy UMT*i*dm f~ rn»«i*§jmr9^ •** *" /•* /•* 

/aim raptmbftflMM pftrpiMi. 

(16) It is somatimas datirabte to aggragata similar items into faattaj jaifa^fw ?p«ortteg 

purpose*. Would you Hto family aggragation to bo considarad for tMs r oa son t 

(Ploaso toy in yas or no): n 

PROCTOR eon nam praaida saa fa ai f aaj asneamfiif mad^-|ari»fiff«o^ ^ mmi/mmUy 

dlmggngmtUn. dtftaa t (aaoapt eam w a w fi aa wo w w tef tj* i n ^dh ifm.lymrf m » inM Is 
ganaratad ay PJtQCTOft /nam its fat a m a l i 
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Concerning the details of a module for family aggregation: Items that experience joint-ordering 
interactions and that are aggregated into families because they share common inventory 
characteristics should be ordered together to achieve benefits of economies of scale. The 
reasons for the decision are that 

1 joint ordering constraints are present. 

2 a module for joint ordering constraints in the purchasing department is feasible. 

A component to handle family aggregation is needed. This is because a module for 
joint ordering constraints in the purchasing department is feasible. A component to handle 
family disaggregation is needed. This is because a module for family eggregetion in the 
purchasing department is needed and a module for joint ordering constraints is feasible. 
Concerning the details of a module for family disaggregation in the purchasing department: 
Procurement amounts that are allocated to families should be allocated to femUy members so 
that items in families run out simultaneously. The reasons for the decision ere that 

1 a module for family disaggregation is needed. 

2 a component to handle joint ordering constraints in the purchasing department is 
feasible. 

PROCTOR starts investigations into external constraints. 

And Mr. Smith, we will now attempt to identify whether there are external constraints among 

your items that warrant the development of an aggregate plan and the eggregetion of items end 

families of items into product types. Do you need further information with regards to external 

interactions? 

(Please key in yes or no): yes 

The presence of external constraints such as storage limitations, financial 
constraints, limited capacity of individual vendors, and need to smooth purchasing orders under 
fluctuating requirements may force the development of a purchasing plan during a long time 
horizon (usually a year). Items and families of items are then aggregated into product types to 
facilitate the design and implementation of the plan. An aggregate purchasing plan is required 
whenever purchasing decisions have to be made looking more than one purchasing leed time 
ahead, and items are competing for scarce resources under fluctuating demand conditions. 

PROCTOR uses auestion 17 through 21 to determine the existence of external constraints in 
KBS Foods. An aggregate planning module is considered if at least one constraint is present. 

(17) Are there storage constraints that limit the amount of physical inventory you could handle? 
(Please key in yes or no): n 

(18) And Mr. Smith, are there financial constraints that force you to define a fairly constant 
purchasing rate each month? 

(Please key in yes or no): n 

(19) Are there contracts you sign with individual vendors which force you to define a fairly 
constant purchasing rate every month? 

(Please key in yes or no): ? 

(20) Are there supply limits on some of your vendors which force you to tnticiptte some of 
your purchasing requirements? 

(Please key in yes or no): yes (' 

(21) Do you carry seasonal inventories to absorb demand fluctuations? 
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(Pioaao % in yw or noh yet 

PROCTOR «***««<•• t*» m a iwlij efo eiw tpimr friat Mi to/ fAe jmnertaaea 

•/lt«HU«IM[«llMHRMl««/lA«|MrMM««««/ltffl 



(22) Are items involved in external mt ot a c t torn InipOrtertf enough to require a special system? 
(these item* might be very expensive or they could be big setter*) 

(Please Key 4n yes Or no): yes 

(23) Do you know what percentage of your Herns art effected by these external interactions? 
(Please fc^ in a value): #8 --* • 

A procurement aggregate p tan i ll ig module w woodad. TNa It because you decided that tho 
axtarnai constraints of tha aurtha ii> » daoartma art important, 

PJWCRBt i w i wi i ty a ii a r ofool a« y frf» « lifer* isallatifaf eg fre«ets alee fnMilUy sfnee 
touts end fmmUim mut mmmlly es /aitaar effrsfetmf ee/eni a ffnsar araginaauibiir 

(24) Can tho itamc (and/or families) affactad by axtarnai interactions ba |roupad into product 
types (eccecdlng h> smwer unit coils, demand pat tad times* 
(Pleas e hoy th yet Br nbfr y. '* 

(25) Now rtow many prootet types are there? 
Pioaao aoloct ona of tha following: 

1 loaathan 11 

2 between 11 snd 20 

3 between 21 end SO 

4 between 51 and 100 

5 mora than W8C 

(Entar hara): 4 

JVetfae tow *H0CI(Nt msaii eamtataaey eaaefti fta/ara eees>is»f an swiwsn it *es daiaetad an 
iM»MiM«»ey e«t*M** »*• npataar a/ feariJist >W i% prn m Mr »/ araWarf» PfM* > f> » * ^ « ** 
•ggr*rttimn. Mr. $mkh r«&th* ti«mt>*fT pr*sW lypei <• e*Z« & 4m*U» » 
chmng* Mt resaenss i i an a aj ninf «** —war ♦/ f m mttht. 



Mr. Smith, I think 1 hava dataetad an arror. 

Tha number of product typat exceeds tha number of families. 
You may changa ona or mora of tha foltewlni. 

1 "between 51 and 100", the response to question 25 concerning the number of the 
product types of the purchasing department 

2 "between 1 1 and 90% the retpoms to quwtton 15 c on c er ning the number of the 
families of the purchasing department 

(Please select one or more): £ 
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So far the following will be changed: The response to apailon 15 concerning the number of 

the famttiefof the purchasing ' 

(Please Key in yes or no): n. '*" 

(15) Mow Mr. Smith, how many families (groups of items) art there? 
Room soloct one of the following: v «, 

1 less than 11 

2 between 11 and 50 

3 betwaen 51 and 100 

4 between 101 and 280 

(Enter here): 4 

PROCTOR aecapu tea eeanae. Preeiau saejeetieiu era amffaaui eed PROCTOR mracaad* »* 

(26) Mr. Smith, do you currently have an aggregate purchasing plan? 
(Please Key in yes or no): ! 

Mr. Smith totarrmau tha mdam le prim fa/ermetJae aamarmng qamtkmM end J*. Wm emit 
details te mm speea.> Nstfea teat eea*fe> ease ease nswaaify dee* 

Question 15 

concerns the number of the femWes of the purchasing department 
response: between 101 and 250 

Question 25 
Ki concerns the number of the product types of the purchasing department 
response: between 51 and 100 



£*£^* eo *^ **• ""J**/* «•* ****** •» s a~r*M ,ri»« Wfap* m 4Sm-*»M 
diwUU* far tha aggragata eiee fa trim f atttmata toe mmMar af oarfsM>M'0»fr«* 




(Pleese Key in yea^pr, np)i n^ 

(27) Mr. Smith, can you give an estimate of an appropriate time hortwn for en aggregate plan? 

Please select one of the following: 

1 leas then 6 months 

2 between 6 end 12 months 

3 more then 12 months 

4 not Known 

(Enter here):! 
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Mr. Smith **ta*t* a AantaaM •/ # aiaia^ /ir f At •* ftv, 
fcr faro w a/ at taa*t • jiaar is la aaa H nt /«r mwnw 

ar# invtf a#d surf iadioatat taa 




Mr. Smith, I tNnk I hava dstactad an arror. 

A tima horizon of lots thin 6 months is inappropriate for a situation with taasonal 
bwantorias. 

You may change ona or mora of tha following. 

1 "lass than 6 months", tha answar to quastion 27 about |h Of tha 
aggragata purchasing plan of tha purchasing dapart ma nt " 1 '' 

2 "presant", tha answar to quastion 21 about saasansJ-invanf « 
dapartmant 

(Plaasa salact om or morah i 

Plaasa try again-- 

(27) Now Mr. Smith, can you giva an asthnata of an appropriate Mi tftrfcbfr f# an aggragsta 
plan? 

Plaasa salact ona of tha following: 

'-• * iaaliwiff'S moh^ 

2 batwaan 6 and 12 months « 

3 mora than 12 months 

4 not known 

(Entar harah 4 

Mr. Smith emmmet dftddt aa a* aaarapriate AantoR. PAX3(^ s%f «astt a Aarisaa a/ 0t. Iaast a 
ysar ana* Mr. Smitfrafrtai. 

(28) It is common to do aggragata planning with a yaar E horizon, b it ok to assums that tha tfnp 
noncwn Dv^fnorv Tnwn ra moninviof^r 

(Plaasa kay *^WWl !e ■ »*""■" 



Jfr. Smith cammn daetfr aa an aparajv-laM dm* aanW ApJatafc. f WCTDJt again r asa s awaa rf i 
ana mama wMcJb UtktmmH kmmm&^&WmWWM „' .' 

(29) What tima parlods do you think you should uaa to dMda your tima horizon? 

Plaasa altaat ona oHha f8fewtng< 

1 1 calandar waak 

2 2 calandar waaks 

3 3 calandar waaks 

4 4 calandar waaks 

5 1 calandar month 

6 1 calandar quartar 

7 1 calandar samastar 

8 5 working days 

9 10 working days 



m 



10 20 working days 

11 4-4-5 wMk division 

12 I dont Knew 



%ni'- 



(Enter here); £2 

(30) It is common to do 
divided toftff month pa 
(Please key in yes or aohx 

PROcroni. 



doegg^te plem^ mj^ tM th* 4|fM horixon bo 





A procurement 
t'tho 

2 a 

Tho number of variables required for tha aggr 
Tha possibility of aggrafating tima periods in 
product typos should bo considered. 
(31) It is somatimas useful to aggregate items 
Would you like product aggregation to b»* "" 
(Please kay In yes or no^ 5 ^ " " 

Mr. Smith rem*** thut q*$$tUn JO as r*$hti. to- 

ml*** of ^mrssftta fiftlf+if* tki ut»i*" *U*. 

*?Vi,fe.i s» aatt «■*«;■;■•: s^-»; ^«k-* .--•.#&»**%- sJF«m. 

So far tr» ftrffowtng win be 1 cndhge* Tha response to 
division 6HW agfrafat* purchasfhg plWWl***;^ 

PROCTOR r—Mlu tae ^mmUm. It May* tip ndfrmimm&m •/ « 
d«t«rmJii«« iAn» pMsiMlity •/ a m*MI« reaft7»reaaartof*aya»tm 










iURK fpHS WHWrW™5f ^Wa •> ! 







.■••^a^.pWTMIQ 



r*.s~" 



(29) What tima periods do you tWnK you shouW in* to j*vido y«jr thiw bor ijton? 
Plsasa salact one of tha following! *;"" ; ■ * .^ 

• I Fc^ionder weoti •■'"'' 

2 2 calendar weeks '" 

3 3 calendar weeks 

4 *«*»«§»• weeks 

5 1 calendar month 

6 1 calendar quarter 

7 1 calendar semester 

8 5 working days * 

9 10 working days 

10 20'worWng s d4yt 
•' v, '« i *>4*%i& 1 e>fjsign-- 
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(Enter hare): 6 



PROCTOR step* 10 «wJ»eta t to poMttllity •/ • mMdie-reaf* fortcaHing system 




Now Mr. Smith, do you need an explanation of tho difference between tho demand for an end 
item and the sNpmants (or sales) of the and itamt , „ _. , vs , „ „ 

(We Will denote % enf it^ ^ th6««Tt^^r tr« raquHted >y a customer.) 

(Wow Hoy in yes or no); yes ", 

Ono should 
from tho ftaat customer 
irtptitt© the 

timing of demand and sales. 

Ceiuteitt tfemftwe' patterns eon |« ftrtad twry dMpljr. iWJJ $*•* efcajejtftlte* 

(32) Do the end items exhibit increesk or decrifiins'lrin^ 
(Please key in yea or no): no *-■*■>*■ . vj^^y,^..^ ..v. ;i .3$.-, 

(33> Aretha and items iffatted by taasonHitla*? 

(Pleaae'fceyiylil dflolt vis'"' " " - t: *-'•'* ' u ^ ' "~ ' :, 

Some eom|NU«l«< fctep reeeiifs •/ ifeir cm* 

(34) Mr. Smith, do you maintain ofniend r« for Most of your fteafs? 

(Please hey in yes or no): q. 



*A 




i«ii 



rt1# jfatliltt all Hltfeffat 



/•reeesrWMia*. ^ fi^r^* Ik* ^^m7. 

ran* a for*caMi*g .^mUr^Urf****^!^** WU sfPH»r% IffcptMffli y 

A as^ae^i^e e^^^e^e^e^si^Aafae^M ^^^^^aT^aooei oTa b 



uggrmgf ate* end te 



F ■ ^e^^p^ j^pp •^aa*' #*^ 



Now do you need a definfftbn of pu ng lead 
(Please Key in yes or no): yes 

The purchasing lead time is the time that elapses from tlW moment a replenishment 
order is triggered untii the first major portion of the order is ptatdOfl tbe «|eJ|f» f PerJj©f tfag^ 
purchasing lead time is caused by internal administrative procelures, and part is due to ln- 
transit time and order processing delays at the supplier. The following e^^^pjmponenta 
of a purchasing load time: .,,.,, 

purchasing lead tine iaaue of 
receipt at purchase ufrefceuee 

requisition 



review 
tine 



vendor quoted 
tead tine 



receiving inspection handling 
tiee tine tiee 



The review time is the time that elapses between the rote ise 

requisition and the receipt of the order by the supplier. It includes an,Wra|f administrative 
waiting time, the buyer's intervention to translate the purchase requWtjon Jfi^aHpurjchase 
order, and the time required to transmit the order to the appropriate vendor, the receiving 
time includes an average waiting time in receiving, and an aoowa nco for counting and checking 



^^^^^#^»^r:^,:- 
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tha ordar. tha impaction tlma (if naadtd), include an avarafa wattim time and th* actual 
impaction tlma. ^ ' 

(38) Ara thara itams with axtramaiy long. purchasing toad tlma*? 
(Ptaaaa hay in yaa or no)t f 



!.-?'. 



Imported iuwumrm U*m* taat Aaat UngUmd timta. 
(36) Do you import any of your purchatad itanwr 
(Plaasa Kay in yat or no): n 



data Utm* km$ mt ftaaa Ha/fraud. 



t*ff 



•fUmglmd 







j n«Ks 



ia Hurwina a nnruramant iSraMaii «ia^^ 



liUfHftMKtt -it, 



PJWatWaWrf^t.o****,* 
iaaf a arfidto waaf fmnnlmg 

Smlm mud ftaaa araar raaajvb aaa la a*W * 
ftmOmi, m ndt m Up td to to t n t ti t nii t m a/df 
■■iriftlHlir «iW emM mt 



«*ffo %d ill:* arow&jioi *«*,? :-- 




(N—,P*OCTO*U 




,_. *s twSjtsSp «S»JI^^Pw%^Hr!l^ff*W'flWWFaii^^*aa* »aa(feailiipa»ai3Bo03«iaaaM ; 
(Ptoaaaliay fa yaa or noVaf. .v,d*«» t»4 fciadt. «*-.*> i. 

(Plaaaa Kay in yss or noF? 






(39) Now k* Smith, do you^ »aja^racor0. bava ai^aj^tf, ^ „ . ? : - 3 } „ w 

I rwlta uv in vm or imiV n 7 , 



(40) Now' ^f^$Wh of yourama, ral^aW ^" *" 



1 toas than ona yaar 
2onayaar 

5 mora than 3 yaar* 



* :£j,«4;rvuss *?'* "* 



"*fc '»*? 



^tf h, *: 



»,-.-.*;:.'* ■ 



-■' i«4**i &?,?>* 



js?si : 



(Erftaf nlf'ajil^ " ; - ~' '■ ' " 
Plaaaa satoct ona of tha foHowii*: 






: C» -c- 



^'■ilai-i-':'<'w\ «*»E!ii*t!'- J-ste tl> •- •>!*% ! '***%'?" ; >;-, & 5^K |C i^alfe^aJi^Sft** :»^ 



'■•W'v 
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1 tty^diy 

2 by week 

3 by month 

4 by quarter 

5 by year 

6 by transaction 



(Enter hare): 3 



PROCTOR eoniwe met* a,««/fatb« dtcUUn mithtrnt kmetm^g tht fiUWky of buck mr$\w 



rVCV^Be* 



A decision concerning •vailabHity tha data for fwecastingof fee wchasjr* dapjrbnent could 

not bo mi<l.<-1*lrtlwfifcW*f "" -i™*« ». W7 >». ..,.,., .. ^ 

OiHtfts «Omo tft. ai 'U s *fO I to-' 
Would you like product 
(Ploaaa Kay in yat or mh I 




So far tha following wW ba changads Tha ratponas to qussttsn 38 concerning beckprder 

records. .*..v «-•»■>* - " T » * •«* ^ *»* ***t s* ««vt-»^»t *.* 

PROCTOR rsesftf (As fMtfJen. 

(38) Da ysv seep reos^ a f badwrdarsf 

(Please Kay hi^ee^ri^yee^ 1 * '«» ' '- ■*»» ^---x^' 

PROCTOR b mm *kt* ****** m 4tMtn.lt 4*U%$Hmt4*U ttkmUabU —dtkmt m 
formatting sy$fm mUmU ft* pesittJa. ^'' Xm " :> ' ,y ' ' v ", ' ' 

Tha data for forecasting of tha purchasing <Jep*rtmertf ts avaltabla. Iff reasons for ft* 
deeieion ara that ■ k ^ >A ''"-" { " 

1 sales records ara present ,....-,-„, 

oacKoroar rocoros in ine purenssfng oapamnant ara present. 

3 errors are absent in tha sales records of the p urchas i ng deportment. 

4 a component to handle mkkJIe-renga forecsstittg pi tha purchasing department is 



5 the length of the sabs racords of tha purchasing department If not toes than one yepr* 

Since you have records of sales and bsckorders that are error free, it should be possible to 
recreate a good estimate of your demand patterns. <?*. ?»^ ^ » 

Ntice, PROCTOR kmom teat at teas* a year a/ imtm will frt ressdres* te kamdh sasaanei 
fmrtmtthtg *,""" 

A component to handle mWdle-ranga forecasting is possible. The reasons for the decision ere 
that 

1 tha data for forecasting of tha purchasing dapartment is ayaJIsWe. 

2 the average length of tha data E foracait^ of Iha tMilS dap^tmant is not (as. 
than one year. -. e --. f ,-, ir ..-, 

PROCTOR rmmmt f U* ovuidmmthm a/ am aggngf piaa. (it wUl eomttmm* f tr tcmt i tt g 
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investigations in a later part of the union.) An aggregate planning module it feasible and 
PROCTOR comments on the type of model that matt he used. (This knowledge could be 
elaborated to provide a more detailed description of an LP.) 

A procurement aggregate planning module is feasible. The reasons for the decision are that 

1 the average number of the variables of the aggregate purchasing plan of the 
purchasing department is not more than 1500. 

2 the average number of the constraints of the aggregate purchasing plan of the 
purchasing department is not more than 1000. 

3 a component to handle middle-range forecasting is possible. 

4 a procurement aggregate planning module is needed. 

Concerning the details of a procurement aggregate planning module: Procurement amounts for 
product types, non-product families and non-product non-family items that are subject to 
external constraints should be determined by means of a linear programming model. This model 
should optimize holding and storage costs while obeying external constraints. The reasons for 
the decision are that 

1 a procurement aggregate planning module is feasible. 

2 external constraints are present. 

Product aggregation is needed to make the aggregate plan feasible. In addition, a product 
disaggregation routine is required to allocate planned procurement amounts to family 
members. 

A component to handle product aggregation in the purchasing department is 
needed. The reason for the decision is that a procurement aggregate planning module is 
feasible. Concerning the details of a component to handle product aggregation: Items and 
families that share common inventory characteristics and demand patterns and that are subject 
to externalconstraints should be aggregated into product types for purposes of aggregate 
planning. This is because external constraints are present in the purchasing department and a 
procurement aggregate planning module is feasible. A module for product disaggregation in the 
purchasing department is needed. This is because • module for product aggregation is needed 
and a procurement aggregate planning module is feasible. 

PROCTOR requires an estimate of family ordering costs before it decides on the type of routine 
to bo used. If costs are small, an equalization of run out times routine will be appropriate. 
Otherwise, Knapsack or Hax-Meal should be used. 
(42) Mr. Smith, please give a rough estimate of the average direct ordering cost. 

Please select one of the following: 

1 less than 0.5 dollars 

2 between 0.5 and two dollars 

3 between two and 5 dollars 

4 between 5 and 10 dollars 

5 between 10 and 25 dollars 

6 between 25 and 50 dollars 

7 between 50 and 100 dollars 

8 more than 100 dollars 

(Enter here): 3 
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PROCTOR nmambm t fat m m fyHm m sresm t*Ufr rs.§ttfeNeW«n*-% Wf**|» •••«*♦ * sues 
i*e maximum •/ tt» ttimfi oatf /ar areerfpf ill tkmimj* ft& * l Mmtly end **W cettt 
for plmdng e typical wuthHtom mmir. 

(43) On the average, how many {tens art thare in an order? 

Please select one of the fottcn*ing: 

1 toss than 5 

2 between 5 and 10 

3 between 11 and 29 

4 between 26 end SO 

5 more then 50 

(Enter hera): 3_ 

Knepfecft b f Jb mott appropriate dl—g grmgmtion rm\dna. 

Concerning the details of a modulo for product disaggraa^ f« department: 

You should uso the Knapsack or Hex-meat desegregation scnwna' in allocating planned product 
type procuremant ewwnts to Jemjy.ar^ ^ 
schemes work be*J dtog ^Usu c h as ; 



the decisrbn are 

1 a component to handle product disaggregation is n aa d ad . 

2 . th> - ^fjWfJf* Iff* rWTi^y ifamofdarj^coal^itp purchasing department ia 
mof» tharf^ Jpta>a. * , , * v . . : ■■ ^ 

■^rplannlng mod^ile^to fajflbJa, -, 

• g*wj^pjp4 Ifxv www I^WwW^BI^w^ p^^ppj IVVBSPMQ^pf,^^ ^^^^Mpppwpppi ^^^^PP^ 
* **•• ■•*- ItUt" Cpif9p»pW» ■» #^ff9 VPpfJp? ■cJp^t^pWpppIpVpi p*PW9pe*Sfc .5wrSS»0ffWPVl^** »*• * p W*We**^**' pwUpFfp 

•eneoie isps .jipia, wpsMi a/4 ay«^iu»,faeapie>*j( t$ e^^pesjpjpaaasjnpeiess •rVitaoia esws. >vaW' 
lead tliiuM or if tht alar /sab Om t.pMsi*fai* ap Jf.aof.sitf aaj paj,^. wepfw nfa»» sa in IW 

(44) How would you crwactefiaw tns variability of yar 
purchased Hams? 

Please select one of the following; 

1 very constant 

2 reasonably constant 

3 fairly variable 

4 extremely variable > 

(Enter here): 3 

(45) Now are the items that exhibit variable lead-timM iirtpc^taot enough to re^nere close 
control? 

(Please key in yes or no): yes 

(46) Mr. Smith, can you give a percent estimate of the number of your items that mrm ef fect e d 
by lead time dependencies? 

(Please key in a value): 15 
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A modute for leed time defwinmetion it needed. The reason for the decision l« that you 
dacl d e d thet thecoma w*b variable mad times of th nt are Important. 



IPfefclaed ■*^^-" t Tr^ A "- jtA irt;- , ffaf rtnti /tmiiifiij inai II jilimfi : ' 
(47* And Mr. Smtth,doee to*m6t^vwMbMrdt^imlM tXikr tixtt 
(Room key fe yet or nbkn ' : "" ■■•;*,:-.•- ■ 

(48) Does the load time variability depend on the season? 
(Please Key in yea or no)t v>WI 

Vondor dopomdomeU$ tritt only mhm tkoro ert mrnlri atntV town. 

(49) Do you have itemt that can be purchased from eeveral different vendor*? 
(Please key in yes or no): n 

(50) Mr. Smith, do you Keep historical records of lead times? 
(Please key in yes or no); yes 

A /ereeestfaf iy#,m fa potdklt etoce mated dtm onit m iu tefat W aim* lied rime rotordt 
era o t ei l oo le . 

A lead time forecasting module is possible. The reason for the decision is that lead time, 
dependencies ere present. Ooneerning the details of a c ompo n en t to handle lead time 
determination: A lead time forecasting system should be Impw m s ntod ior Items that have 
Materialised tmm deimiioeiftwt/ttm^ flsimn iialfill ' - 

'-■ • ■**aB4ae #tl i m»faMw a tlliy metfale is possible. l> *"••" ~'" : '-' 

2 seasonal lead time d e p e nd e n c i es ere present 

™0CTtMI **«« t*at b cojuwh /«**«• ««i«et« mp^tfor long l—d timo* d»co it doo$ not 
nrrrmll i ife liitiifi tftfofrfafr rilJ riW^ IJMl^llF^llIt****** 



A decision concerning the type of a module for long lead time <*terminetk>n could not be mode. 
The reason for the dteWon it that ft is not knowrt^h*th#f long leadtbSitem. ere j» eienX 

PROCTOR biimMimHsttgotion, into —dor itftcri aj 



Ma vomdm eiteafaft oompomm fa rate*** abet mmtttmU tender iteeu era •»«**: 
fmwMf^aHoiM ere net eentfaeed. 

raat^^he°decitiorf*^ 



PROCTOR btgin$ en Imwulfetieii Jafe u modult f imtonoim mrdor apaaiflfri Jar 
•ggrtgofly plommodkom* mmt ~ ~ '• ""- ' iV *"' w:7 ^* ■ 



And Mr. Smith, do you need an explanation with regards to the components of holding coat 
essocieted with carrying a unit of en item in inventory during a year? 
(Ploaoo Key in yet or no* vet ,,--m^>- 

The primary components of ths Inventory holdirw cost are; cost of capital tied up 
in inventory, handling, pilferage, pemage^breaKage, rust, de^fta* evWatioX 
obtOlesence, storage, insurance, taxes, etcl normetfy, the W m^lnFce^ients of the 
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inventory holding cost* ere the. ©wit of capital and. tax*. Tha relevant part of these costs te 
that one that ia djrecto variap> with inver^ory va^ since tha in si d s m s of tre^ components 
in establishing the inventory tolling coats depends on tha unit coat of tho item, tho impact of 
thoao compononta ia combined into ,a single f igwa ^ap^ ^a ^^^ .4t^^ »ataant«t« of tha unit cost 
of tha itom which acq £*y *o*t T^Jc*o«sj||»lsv* aa> item with e unit cost 

of tlO.00 haa a 20* holding coat it maana that it coat 12.00 to keep a unit or t hot Moat in 
inventory for a year. 

(51) And Mr. Smith, what is tho purchaso cost for most of your items? 
Ploasa saloct ona of ths following: 

1 loss than 05 dollars 

2 botwoen 03 and two dollars 

3 between two and 5 dollars 

4 between S and 10 dollars 

5 between 10 and 25 dollars 

6 between 25 

7 between 50 and 

8 more than 100 dollars 

(Enter here): J 

Mr. Smith ha* jot r—Wui tee* As *•«• a «*•*# sen so r te feeajlip #> Jfeae^ois«y lieass 
that ere mepHsd by mere than en* seeder. #« iMfrup U PRUpTOR t+ r* m m*tt thai a **» »* »* 49 
ae reankmi. _,,.-. 

So far the following will be changed: Tha answer to question 49 concerning multi-vendor items 
in the purchasing department. 

PROCTOR rtasku M* yuttlom end rweestfmtai ill sealaaHpni /er lead tim* tmppcrtamd eeeder 
mppart. 

(49) Do you have items that can be purchased from several different vendors? 
(Please key In yes or no): yes 

/Vote that am ammar afK* % • oaestls* 52 Uaan tee p r s stse s sasfootfans sa n aswdw f lead time 
mpport umff*ofm\ PROCTOR dmply $Um4 ti* r 9 $mt i mm Hmv $* 4 jw a o as rf i ** fn s o s tf e oM o 
vtndor safeeHde MmpaMM. ""'" 

(52) Do different vendors hay* tignifksntly oNffarsnt purchasing lead timas? 
(Please key in yes or no* n 

fner* an we gender tradaoffu to e mmaaU for v$n4 o r ssJaejtogis aiw s o a i aary. 

(53) Mr. Smith, does the price of the item change with eachmdMdual [vendor? 
(Please key in yds or no): n r. ,.«c, 

A module for vendor selection is unnecessary. Tha reason for the decision is that vendor 
tradeoffs in the purchasing department are absent. 

PROCTOR ctnttnmsi at tho poiat whoro U mu iMtrruptoi. 

(51) And Mr. Smith, wtlst is the purchase coat for most of your items? 



143 

Please select on* of the following: 

1 less then 0.6 doltsrs 

2 between 03 end two dollars 

3 betwedh^twoarm'tdeliert 

4 between 5 and 10 dollars 

5 between 10 and 25 dollars 

6 between 25 

7 between 50 

8 moro than 100 doltars 

(Enter here): 3 

(MH*< fm«h, provW. a rough estimate of tha ftwantory hotdk* fewt oAprosied m a 
parcantago of tha Itam't unit cost. ^ r '-"' 

Plaaaa select one of tha foHowingi 

1 lass than 10 parcant 

2 between 10 andlO percent 

3 batwaan 15 and 20 parcant 

4 betwean^emi 20 percent 

5 batwaan 25 and 30 parcant 

6 mora than 30 parcant 

(Enter hare): 4 




From pnvi c mt *oltMt*Un$ csftmnda, ****** east* ($mtym t» 
routi$»)m*d frmmftMl** S9+* 14, IW(^ *$&**% 

eeesjensle order eowMeW rikttto-Yf%i'l'JH '^U^wl«KW'£ i^ 
»«J"9<»o coiicer**** tee attsafMWy a/ JOQs /or atJlfoW 

A routine for computing eoq's is possible. TO* is because s modutft for nMdto-r snga 
forecasting is possible and tha estimated family and non-fsottty Ham ordering coat of the 
purchasing department is not less than two dollars and tha s^Mtf fifltfry and ndMemfly item 
ordering cot of the purer, ». » « dope, tm ant dMdsd% tha etfestt hWfcc^W of W 

purchasing o*paftn^tttnofm%»1hen 0.05. • ^•^"--^ '" ' -«* "' - >r 

toplmdMhmmu relet itfrmin* tat type •/ EOQ /sremfe te km uW. 

(55) Do you have any items whose purchase orders era not received eH at oncet 
(Please key m yes or no* £ J , T 5 - r 



PROCTOR rsmofiuWf teat eeeneaiMi •/ seal* art present ami reesmmemis fact a fafcaftle 

r 'Trtr antf fn twin naffi iiiseiiniii tf jiiiIj. 



Concerning tha details of a routine for computing «oo> Order *ier«ties may be determined by 
the standertfooqforpuister most* your *•*«. ThoM^He^^ e*pe¥i 
instantaneous raplenishmant rotes should use tha eoq formula that takes replenishment rates 
into consideration. A formula that takes economies of scam into considarstton should be used in 
determining the order quantities of 4temt sw dfaw flta s trmt h a ve cOif iW V Q^ o ml i r of scale In 
ordering from vendor*. TWa Is basa u ss sroutmsfc» uwapuW» eoo^ % posetole end a module 
for joint ordering constraint, is feasible and joint ordering constraints ere presort and items 
with non-instantaneous raplenishmant rates in tha purchasing dapaYfmaWeWprecent. 
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Spodal mpport it roquirU far tsireataly ttptrnd* if ami. fJa/aruuMtaty, PROCTOR ammnot 
make an evaluation fcassd on Iff. Smith** anttoer*. 

(56) Art there extremely expensive Items that deserve a special control system* 
(Please Key in yes or noh ? 

A decision concerning the necessity of a routine for determining order qusntttiss of extremely 
expensive items could not be mode. This is because it is noMifRiiimWbelher extremely- 
expensive items in the purchasing department ere present. 

PROCTOR eompUtw imvettlgatton* into foroeasting 

(57) Do you keep records of teasonsl indices (or seasonal factor*) for the seesonat end items? 
(Please key in yes or no^ ! 



Mr. Smith hat othor idaat: ha aodio* ta ehangt hU anmor canaamim* 
raplanUhmant rata*. 

So far the following will be changed: The response to question 5& about items with non- 
instantaneous replenishment rates, rtcenter BxoomAon emtio*** 
(55) Do you have any items whose purchase orders are not receh^oll efc once? 
(Please key in yes or no): n 

PROCTOR recompute* tha evaluation af tha detail* af tha BOO routine hut moat no* recompute 
the evaluation* into tha tmitehUUy of am BOO routine. 

Concerning the details of a routine for computing soq>K The standard e«OJiaj|# ojder ajiienMty 
formula should be used for mo«t of your If that take* eco n o m i es olscsis into 

com should «ed In datermioingthe order quentttiasgt items so d f a mili es f hot heve 

certain economies of scafe in ordering, fro* vendors. , The aoes for Pm tjhs c i e i oiv are that 

1 a routine for computing eoq's is possibb. 

2 a moduja > for )oint,ordsfing<»ostreints is feasible. 

Forecasting eontideraiion* aontbma* 

Record* af pooeenul l*di u oaumte of iota (or faroae*$i*M , *—mml item*. 

(57) Now db you keep records cif seasonal indices (or seasonal favors) for 4be soesonel end 
items? 

(Please key in yes or noh n * , - 

A system i* still pouiels dm* PROCTOR ho* previoudj det ermined thatiam far f o roomoHmg 
i* available. 

A component to handle the forecasting of seasonal, items is possible. * The - j»ae*r*> tor the 
decision are that 

1 the data for forecasting ff the purchasing department Ja available. 

2 the average length of the data for forecasting otihe pure h aa iag d e p a rtm e nt is wot less 
than one year, * 

W '^^Bf^pSgp*. {IN Is fajp ■^BWPaHP^ : vB»i"^f"Jf^B S^ppjf g|r;yS*BW-^g^^ijMSJP¥mPm v ^f^Pe>eWe 

(58) How many different seasonal potterne do you haveemong your end items? 
Please select one of the foiiowingt 
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1 1 
22 
33 
44 

5 5 

6 more than 5 



(Enter here): 6 



Umifd «J« m«jm it.ms «rt tm mm t t ifwu «M«* fee* >•*•* •fmmU*. KfiSh** 
mcft ifnu (Chrlstm— emmiy, fmt numpl*). S»»«—» mm mMf U jew i ii s a* with tO* 
■■■i f wo f ffcmaHmf, tytfm : .- ,,.,. ■,. 

(59) Do you have wMmt Rom whose demand suddjijfy terminate* at the end of the season? 
(Ptessefcey In yssor noli jfgg -'■""■■■- <-■*-■ ■' ^*" ■■-* " 

(60) Are fh*ts limited sates season Items Important enough te requke • sptclai control system? 
(PIomo koy In yot or no)t yes. 



tho ond of Jhjseeson? ,....;.,., ..>..,...«, 

Pteaee select one or more of the following: 



1 Fastest selvage value 

3 writ* off st obsctete 

(Enter hero): 12 

(62) Approximately what percentage of your end items art eod-eaeson items? 
(Pteasekeyinavatuefclg 

A module for tho forecasting of Hmited-ssles-sesson item* it rwaoadV This ittmiuM you 
docidod that tho limitod-aslos soes o n Items of tht purchasing dspsrtmsnt s»w teportant 



ifms wUl bf <*MffU4 M weotel «•«*•/ iU mw4 ^ wi|« /mmiI% lyOt*. 

(63) Ar. there slow .moving items ft*, items with demand of less Ihe&fjvee *#* por month)? 
(Pfoaso KoyJo yes or nofc yes 

(64) Aro these slow movors important enough to require • special control system? 
(Please Koy in yes or noh yes 

(65) Can you give a the percentage of Items th»t srs *k*w raovar »? 
(Please Key in a value): ? 

A module for the f orecatting of alow-mpyjag item U osedfoV Th»r«««en for ths dscmlon is 
that you decided thatths ^ptow-mpvlng iteny of u^ fwyh pitjg^artemot #f* frgJftont* A 
component to hartdlo the forecasting of slow-moving Warns mpojafWa. The reason for the 
decision is that the data for forecasting of the purchasing department is avsHsbie. 
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Concerning the details of a module for the forecasting of slow-moving items: The 
forecasting of demand for slow movers can be done by exponential smoothing with e vfrjr smell 
smoothing factor. This is because a module for the forecasting of stew-m ov ing items \%f$» 
purchasing department is needed end a component to handle the forecasting of slpw-movJng 
items in the purchasing department is possible. A module for the forecasting of seasonal items 
is needed The reason for the decision is that seasonal Kerns are present. 

(66) Are there items with lumpy demand (U erratic demand behevior where periods of very 
slow demand erf followed by sudden high domafid roo dr p m a n ts)? 

(mm*My in yes of rid): n " " _" *** *" '^ ' ;/ 

A module for the forecasting of items with erratic demand is unnecessary. 'The reason for the 

with trends are absent. 

(67) Po you have fesNonable Items (i*. items that bavp • short sellir* l(fe, Ngh obs q l f se nco , 
and Bmited l^der Opjwrtunftle*)? . ; 

(Please key in yes or no): n 

A component to handle the forecasting of fashionabji HeiM unnjfcegMry. This is because 
feshtbribte items iri absent > , 

(68) Do you carry promotions that greatly affect the demand pattern of your end items? 
(Please key in yes or no): ? 

A decision concerning the necessity of a component to handle tMJorj^|p. ; pf^p|^mo|ed items 
could not be matie. This is because it is not known whether praiwej 

(69) Mr. Smith, do you cerry advertising csmpaigns that greatly aripp% and' IMwPrh of 
your end. items? «.•.;:■,-?.-.«-,, 

(Please key in yes or no): ? 

A decision concerning the necessity of a component to handle the forecasting pf advertised 
items in the purchasing dapsttment cootd hot be maderTteVls becsusl II not loliown wnether 
advertised items are present. 

(70) Do you think it is important to provide support for predicting the growth, maturity and 
decay of your items? *' : * ' 

(Rease key inyesornoHn . ""■ "'■'■''■ '""" 

A module to mipport the pr^dkm of Item Hfe pttief rw l« urmecewsry. The 
reason for the deeistewls >het yw < ^l d s d f h«t the tuppOii c^1>reo1ctton Item-iffe it 
unimportant. 

(71) 00 yen nave abr««ii8lly large orders <Aie to' spec^ thet 
you hendle as special orders you would like to be screened out of WL «6%il fnwiiolr> control 
procedures? 

(Reese key in yes or no); yes ' 

(72) Now are these abnormally large orders (due to special orders, errors, promotions, etc) 
frequent enough to require a routtne system to be set up " ' 

(Please key in yes or no): n 

A module to fHter large orders Is unnecessary. The reason for the decision is that ybu decided 
thet the control of items thst experience lerge orders of the* po|thttfr«j^^oNi0tHiMitt la 
unimportant. •■*'" - *v. >• - - 
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PROCTOR can mm dcacribc tht detail* •/ the mtdult /«• midiU range fartatting mpport. 

Concerning the details of • component W handta nwttU-rtntf for««sting: The 
demand for product types, non-typa families and non-f tm»y noh-typa It bo forecast 

by exponential smoothing. These forecasts m«y b« (f«aurM^fd aaordiM to ttmreJitJve 
annua* demehds or menders. Demand for slow moWs t3? I» Wsce»f by fKPOntotJal smoothing 
with • small alpha. TNs is because a module for theforicistW < eeea|^ Item* In the 
purchasing department is needed end • component to handto the forecesttng of seasonal Items 
is possible end a module for the forecasting of sjow-mpj^ijems in tnepurefcasing department 
is neetfed ontf*a modofe for the fbrecftyttng of ttow-iw&nj imkbpdu&b *#•{ procurpppnt 
eggregate planning module is feasible ore mMiyrorW%rl^cp^pf is feasible. 

TM$ compfam a fint —$$hnt. PROCTOR rmtumt te tarn ieeef and aim* fair furthmr instruction*: 
r*$pcn*u cen ha ehotkoi far c a m c tnaut mmhaOmm may kt m m m m rlfd . Mr, Smith dacidit tm 
mmaa tha tauten bafara eamttmtng any fmrthmr. A feed MeeT 

You ore at top level. Pleiss select one of the foWowing: 

1 quit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 1 

And Mr. Smith, do you really want to quit? 
(Please Key In yes or noh ,yW 

Do you wish to save what you havio^»nt so fart 
(Please Key in yes or no): yes 

A record of this session will be saved Do want a listing of the session submitted for printing? 
(Please Key in yes or noh n 

Welcome bacK Mr. Smith! 

Today is April 27, 1978. The time is 843 pm, 

You are continuing the analysis started on April 27/H76 at 7:38 pm. Yt9M** at top Jevel. 
Please select one of the following: 

lquff ■-•-■^• v *■■ ■■''■'":"■':■ \'''" f Z : . ..'.'.' 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 
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Mr. Smith doeiiot that mmmmI l—i Urn* i§ ptmUmokt oro wot tk$ »omreo e/ CBS's variable 
load timom ht roquostt e chango to futthn 44 

The current question numbers range from 1 to 72. Please key in the numbers corresponding t© 
questions whose answers you wish to chengs. 
(Please key them in): $4 

So far the foflovring wilt be changed: The response to question 44 concerning the degree of 
variability of the fead-times Of tha purchasing department. 

Do you want to change any more? 

(Please key in yes or no): n 

Do you wish to delete any requests? 
(Please key in yes or no): n 

(44) How would you characterize tha vsrisbility of your purchasing teed times for most of your 
purchased items? 

Please select one of the following: 

1 very constant 

2 reasonably constant 

3 fairly variable 

4 extremely variable 

(Enter here): ! 

An orron Mr. Smith roonoatoi tho wrong emouiom la ht roa&oi. £» irtermpts PROCTOR im tee 
middle of a ehongo and roomom that auottiom ooehaagod. 

You are at top level. Please select one of the following: 

1 quit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 

The current question numbers range from 1 to 72. Please key in the numbers corresponding to 
questions whose, answers you wish to change. 
(Please kiy #m inr# 

So far the following will be changed: The response to question 48 concerning seasonal lead 
time dependencies in the purchasing department. 
Do you want to change any more? 
(Please key in yes or no): n 

Do you wish to delete any requests? 
(Please key in yes or no): n 
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PROCTOR must still reask question 44. 

(44) How would you characterize the variability of your purchasing lead times for most of your 

purchased items? 

Reese select one of the following: 

1 very constant 

2 reasonably constant 

3 fairly variable 

4 extremely variable 

(Enter here): 3 

The response to question 48 is now being changed 

(48) Now Mr. Smith, does the lead time variability depend on the season? 
(Please key in yes or no): n 

There are now no lead time dependencies so a lead time forecasting system is inappropriate. 
(Notice, this section illustrates PROCTOR'S environment mechanism. PROCTOR has invalidated 
all references to evaluations concerning lead time forecasting.) 

PROCTOR considers alternative variable lead time support. Emergency lead times can be used 
when items are unexpectedly understocked. Safety lead times are useful in providing 
insurance against stock outs. 

(73) Now do your vendors quote an "emergency" lead time for critical items? 
(Please Key in yes or no): yes 

(74) And Mr. Smith, whenever the purchasing lead time is quite uncertain, a safety lead time can 
be added to the average lead time to take into account the uncertainties associated with lead 
time calculations. Do you favor the addition of a safety lead time? 

(Please key in yes or no): yes 

(75) Are there quantity restrictions associated with the emergency lead time? 
(Please key in yes or no): yes 

(76) Now Mr. Smith, is there a price increase associated with the emergency lead time? 
(Please key in yes or no): yes 

PROCTOR redetermines the details of a system for lead time support. 

Concerning the details of a component to handle lead time determination: A safety lead time 
should be added to your best current estimate of the procurement lead time when order 
amounts are to be determined. Emergency lead times should be used only when items are 
unexpectedly stocked out. This is because emergency lead-times are present and restrictions 
are present and you decided that the safety lead-times of the purchasing department are 
appropriate. 

PROCTOR has nothing more to do: it awaits further instructions. 

You are at top level. Please select one of the following: 

lquit 
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2 continue the analysis 

3 help 

4 change iniwtri 

5 summarize the analysis 

(Enter here): 4 

Mr. SetitA i« mm tatUfloi arftft ta» mm ewertsr rime pe n M /er (As aggrogmto pla* and mwrm 
tAst evesrien 19 e« rwesasd. 

The currant question numbara ranga from 1 to 76. Plaaaa Kay in tha numbars corresponding to 
questions whoaa anawars you wish to change. 
(Plaaaa kay tham in): 29 

So far tha following will be ehangadi Tha answer to question 29 about tha tima parted division 
of tha aggregate purchasing plan of tha purchasing department 
Do you want to changa any mora? 
(Please key in yi 



Do you wish to delete any requests? 
(Plaasa Kay in yes or no): n 



i yas or no): n 
(29) What time parlods do you think you should uso to divida your time hpftaen? 
Plaasa salact ona of the following: 

1 i calendar waaK 

2 2 calendar weeks 

3 3 calendar weeks 

4 4 caJeftfaVwoaJts 

5 1 calendar month 

6 1 calendar quarter 

7 1 calendar semester 

8 5 working days 

9 10 working dsys 

10 20 working days 

11 4^ week division 

12 I dont know 

(Enter here): 5 

Unfortunately, Mr. Smith forgot why ho ehoto taeh an *£ $*»fiU* ttntojtortod: am £f. 
infeoMiblewdiu ttmi port > miouJm jifeatrefe* 

horn PROCTOR Hood set roeompnu «*» oWro Uatho tm fm mo t i on. 

A procurement aggregate planning module is infeaslbM. this is because the average number of 
the variables of the aggregate purchasing plan of the purchasing department is more than 1500 
and • procurement aggregate planning module if .ijoadasV Tha nmp o r ^vfria^o* required for 
the aggregate plan makes it computtttonaffy imprectksl. The possibility of aggregating time 
periods in the planning horizon or further sMrsgatkig product types jteuld be considered. 

In changing tho nmmoor of Onto moriodt, Mr. Smith affootoi tea soafe o rt e a a/ tat fooMkUUy 
of an aggro goto plan and fa tern, tho tmUot io nt for tat mUdlo romgo foroeoming system. // 
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a Bw£5£ZZ at * P,an U inf€aMU ' U "*** be that "• mUdU range forecasting system is required. 
PROCTOR, therefore, recomputes evaluations of forecasting that are affected by the change in 
the evaluation of aggregate plan infeasibility. Here, a middle range system it still required 
line* tupport it needed for a joint ordering interaction* module. 

Concerning the details of a module for middle-range forecasting: The demand for 
product types, non-type families and non-family non-type items should be forecast by 
exponential smoothing. These forecasts may be disaggregated according to the relative annuel 
demands of members. Demand for slow movers can be forecast by exponential smoothing with a 
small alpha. This is because a component to handle the forecasting of seasonal items is needed 
and a component to handle the forecasting of seasonal items is possible and a module for the 
forecasting of slow-moving items is needed and a module for the forecasting of slow-moving 
items is possible and a component to handle joint ordering constraints is feasible. 

Evaluation! of the necettity of product aggregations are affected. Mr. Smtih states that he 
doet not want aggregation for reporting purposes. PROCTOR concludes that product 
aggregation it unnecessary hated on current evaluations: tehy aggregate if an LP it infeasible? 

(31) It is sometimes useful to aggregate items up to the product level for reporting purposes. 
Would you like product aggregation to be considered for this reason? 
(Please Key in yes or no): n 

A module for product aggregation is unnecessary. This is because a procurement aggregate 
planning module is infeasible. 

PROCTOR returns to the top. . . . 

And Mr. Smith, you are at top level. Please select one of the following: 

1 quit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 

PROCTOR attumed a time horizon of more than 12 months for the aggregate plan. Mr. Smith 
decides to specify a horizon of 6 to 12 months hoping that this will change the number of 
variables in the LP. (Clearly, an explanation system and some tort of debugging facility teill 
someday be required if the user is completely unfamiliar with the methodology. We assume, 
however, that the uter it intelligent enough to know that such a change can affect the number 
of variablet in an LP.) 

The current question numbers range from 1 to 76. Please key in the numbers corresponding to 
questions whose answers you wish to change. 
(Please key them in): 27 

So far the following will be changed: The answer to question 27 concerning the length of the 
horizon of the aggregate purchasing plan of the purchasing department. 
Do you want to change any more? 
(Please key in yes or no): n 
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Do you wish to delete any requests? 
(Please hey** yes or nofcn 

(27) And Mr. Smith, can you give an satimata of «n eppropriate time horizon for an aggregate 
plen? 

Ploasa selact ona of the following: 

1 toss than 6 months 

2 beNreen 6 end 12 months 

3 mora than 12 ! months 

4 not known 

(Enter hara): 2. 

Wba aoaiuatiam ktmmt emmgow\ PROCTOR dm/if romfflmt ks u row Umi es oft te tl o a s. 

A procurement sggregata planning module is infsssibia. This is because the swage number of 
the variables Of tr* tfgrefete purchasing plan j» more then 00 

snd a procurement sggregafflffiimNihg module k needed. miWm WJMm. 

the aggregate plan makes it computationally impractical. The possibWty Of sggregsf intf time 
periods in the planning horizon or further aggregsting product types |.cjNnsjdeeecL 

Concerning the detsfls of a module f©r mkk*s-r«nge ton in the '0ft$mn% ant: 

The demsnd for product types, non-type families snd non-family noh^pemtna should be 
forecsst by exponential smoothing. These forecests msy be disaggregated according to the 
relative annual demands of members. Demand for slow movers can b#%r»ce|t o> expohehttei 
smoothing with a smsil alpha. This is because s component to hsnje the forecasting of 
seesonsl items in the piirchastng depertmsrtt fe needed and • module for ths forecssting of 
seesonal items is possible snd s component to handle the forecasting of slow-moving items in 
the purchasing department is n ee d ed and s component to handle the,?** *"• 

items in the purchasing department is possible snd s procurement faaii^Mi^Maaf ' 

feasible and a component to handw joint ordering constraints is feasible. Aj c wm^onerw to'l 
product aggregation in the purchssing department is unnecessary. This !• 
procurement aggregate planning module is infessiWs. 

You sre st top level. Please select one of the following: 

1 quH 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the snsh/sis 

(Enter here): 4 

Mr. Smith renumbers tkmt ho did not specify \*hethm*om\or eentrmets '**** -'fjrdssift. Vo "Aeper 
to remove the infeedkility seafeeriew ay completely tmodfying tea problem. 

So for the following wdf be changedt The response to quests It concerning vendor contracts. 

PROCTOR continues execution. ... 

Notice that this chemge ho* eheelutoly no tffoet on tho epeluetton. Tho chemge le tho number 
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of constraints does not affect the evaluations since an aggregate plan is already infeaMle due 
to too many variables, 

(19) Are there contracts you sign with individual vendors which force you to define a fairly 
constant purchasing rate every month? 
(Please key in yes or no): n 

You are at top level. Please select one of the following: 

1 quit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis 

(Enter here): 4 

Mr. Smith finally takes the most reasonable course of action. With a little thought, he becomes 
convinced that there it more product aggregation than he had originally specified. He 
therefore requests a change to question 15, 

So far the following will be changed: The answer to question 25 concerning the number of the 
product types of the purchasing department. 

PROCTOR continues execution. . . . 

(25) And Mr. Smith, how many product types are there? 

Please select one of the following: 

1 less than 11 

2 between 1 1 and 20 

3 between 21 and 50 

4 between 51 and 100 

5 more than 100 

(Enter here): 3 

PROCTOR recomputes only affected evaluations. It does not review the entire session. It finds 
affected changes by following direct dependencies Notice that the problem i$ now feasible but 
with a different set of conditions: the number of product types has decreased and the number 
of time periods has increased. 

A procurement aggregate planning module is feasible. This is because the average number of 
the variables of the aggregate purchasing plan of the purchasing department is not more than 
1500 and the average number of the constraints of the aggregate purchasing plan of the 
purchasing department is not more than 1000 and a component to handle middle-range 
forecasting is possible and a procurement aggregate planning module is needed. Concerning the 
details of a module for middle-range forecasting in the purchasing department: The demand for 
product types, non-type families and non-family non-type items should be forecast by 
exponential smoothing. These forecasts may be disaggregated according to the relative annual 
demands of members. Demand for slow movers can be forecast by exponential smoothing with a 
small alpha. The reasons for the decision are that 
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1 • component to handle the forecasting efeiseonatttemt la needed and a module for 
the forecasting of seasonal items it possible. 

2 a component to handle the forecasting of stew-moving Hems is needed end a 

3 a procurement aggregate planning module is feasible of * &fiptbmr# to handle joint 
ordering constraints is feasible. 

A component to handle product aggregation is heeded. 'TtiPrealoh f#the decision is that a 
procurement aggregate planning module is feasible. A component to handle product 
disaggregation is needed. TNs is because a component to handle product aggregation fc 
needed and a procurement aggregate planning module la feasible. (Jbwernlrigtri details of a 
module for product disaggregation: You should we the Knapsack or Hex-mealdii 
scheme in allocating planned product type procurement amounts MmWM w «" 
members of product types. These schemes work best for situatiofW^»Wal«u|la#1iii* 
costs such as yours. TNs i* because a module for product dlaaggregation in the purchasing 
department is needed and the estimated femNy and non-family item ordering cost of the 
purchasing department is mere then two dollars end »pr ocurj Nwj ^ aeja| , ejttte plenj^ mOjdjUJ*,,. 
is feasible. Concernfng the deteih of • eomponerirtof«r^:pT^W and 

families thai share common i 
to external constraints should be aggregated into i 
planning. The reasons for the decision are that 

1 extemai cOr*tfainf» ; srepreient. 

2 a procurement aggregate planning module if feasible. 




Concerning the details of a procurement aggregate pfaj^iK (Mduie: ^ocu/jaieani amounts for 
product types, non-product families and non^rod^t t^ fw i« y Items that are subject to 
external constraints should be determined by means of a w^aarjrjwiiimj^ 
should optimize holding and storage costs whHe obeying a^afril constraints. This m because e 
procurement aggregate pfenning module is feasible end external constraints are preeent 

You are at top level. Please select one of the following! 

1 quit 

2 continue the analysis 

3 help 

4 change answers 

5 summarize the analysis .... ,....$<?... „.«., , 

(Enter here}* 5 



K*****: t :**:Mi*:Mg***»*^^ 



Mr. Smith iptUei to gtt eomfilit* tt$dm 

and kUMk^'^m&f^^^ 
lib* UM/nffttJ pi 

The followhig is a list of possible summaries. 
Please select one or litbrO of tr# folfowmg: 




PntfCtWr* #ee4aa|lejia 
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1 print a summary of the facts collected 

2 print a summary of the recommendations so far 

3 print responses to questions 

(Enter here): 12 3 

A summary of fact* determined by PROCTOR. 

Date of session: April 27, 1976 
Time session started: 8:03 pm 

User's name: Mr. Adam Smith 

The following data is about KBS Foods Ltd 

The address of KBS Foods Ltd is Cambridge MA 02146. The activity of KBS Foods 
Ltd is purchasing. 

The number of the purchasing departments of KBS Foods Ltd is One. 
The following data is about the purchasing department. 

Concerning the number of the items of the purchasing department, there are many. 
The number of the items of the purchasing department is between 5001 and 10000. Joint 
ordering constraints are present. You decided that the joint ordering constraints of the 
purchasing department are significant. It is not Known whether joint quantity discounts are 
present. 

Common ordering costs in the purchasing department are present. Joint economies 
of transportation are absent. Economies of transportation are absent in the purchasing 
department. Complex orders in the purchasing department are absent. Multi-item orders are 
present. A component to handle joint ordering constraints is needed. A component to handle 
joint ordering constraints is feasible. Concerning the details of a module for joint ordering 
constraints: Items that experience joint-ordering interactions and that a hare common inventory 
characteristics should be aggregated into families. The percentage of family items of the 
purchasing department is 70. On the average, the number of the family items of the purchasing 
department is 5250.7. You decided that the family aggregation of the purchasing department is 
possible. Your desire is to not aggregate families for reporting purposes. 

The percentage of non-family items of the purchasing department is 30. On the 
average, the number of the non-family items of the purchasing department is 2250.3. 

The number of the families of the purchasing department is between 101 and 250. 
A module for family aggregation is possible. A component to handle family aggregation in the 
purchasing department is needed. Concerning the details of a module for family aggregation: 
Items that experience joint-ordering interactions and that are aggregated into families because 
they share common inventory characteristics, should be ordered together to achieve benefits of 
economies of scale. The number of the product types of the purchasing department is between 
21 and 50. 

On the average, the number of the product types of the purchasing department ia 
36. A component to handle family disaggregation in the purchasing department is needed. 
Concerning the details of a component to handle family disaggregation: Procurement amounts 
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that are allocated to families should be allocated to family members so that items in families run 
out simultaneously. External constraints in the purchasing department are present. You 
decided that the external constraints of the purchasing department are important. The number 
of the external constraints of the purchasing department is two. Seasonal-inventories are 
present in the purchasing department. Vendor supply-limits are present in the purchasing 
department. Vendor contracts are absent in the purchasing department. Financial constraints 
are absent. 

Storage constraints are absent in the purchasing department. Seasonal items in 
the purchasing department are present. The number of the types of seasonal items of the 
purchasing department is more than 5. 

You wanted assume the length of the horizon of the aggregate purchasing plan of 
the purchasing department. The length of the horizon of the aggregate purchasing plan of the 
purchasing department is between 6 and 12 months. 

On the average, the number of the variables of the aggregate purchasing plan of 
the purchasing department is 864. On the average, the number of periods the aggregate 
purchasing plan of the purchasing department is 12. The average time period division of the 
aggregate purchasing plan of the purchasing department is one month. The average length of 
the horizon of the aggregate purchasing plan of the purchasing department is 12 months. A 
aggregate purchasing plan in the purchasing department is absent. Your desire is to assume 
the time period division of the aggregate purchasing plan of the purchasing department. The 
time period division of the aggregate purchasing plan of the purchasing department is one 
month. On the average, the number of the constraints of the aggregate purchasing plan of the 
purchasing department is 864. 

A procurement aggregate planning module is needed. A procurement aggregate 
planning module is feasible. Concerning the details of a procurement aggregate planning 
module: Procurement amounts for product types, non-product families and non-product non- 
family items that are subject to external constraints should be determined by means of a linear 
programming model. This model should optimize holding and storage costs while obeying 
external constraints. The percentage of aggregately-planned items of the purchasing 
department is 65. You decided that the product aggregation of the purchasing department is 
possible. 

You didn't want to aggregate product-types for reporting purposes. A module for 
product aggregation is needed. Concerning the details of a module for product 1 aggregation: 
Items and families that share common inventory characteristics and demand patterns and that 
are subject to external constraints should be aggregated into product types for purposes of 
aggregate planning. A component to handle middle-range forecasting in the purchasing 
department is possible. A module for middle-range forecasting is needed. Concerning the 
details of a module for middle-range forecasting: The demand for product types, non-type 
families and non-family non-type items should be forecast by exponential smoothing. These 
forecasts may be disaggregated according to the relative annual demands of members. Demand 
for slow movers can be forecast by exponential smoothing with a small alpha. Items with 
trends are absent in the purchasing department. The data for forecasting of the purchasing 
department is available. The average length of the data for forecasting of the purchasing 
department is more than 3 years. Demand records are absent. A decision concerning the 
necessity of a module for long lead time determination could not be made. 

A decision concerning the type of a module for long lead time determination could 
not be made. It is not known whether long lead time items in the purchasing department ere 
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present. 

The degree of variability of the lead-times of the purchasing department is 
variable. Imported items are absent in the purchasing department. Sales records are present. 
Data errors are absent. 

The length of the sales records of the purchasing department is more than 3 years. 
Backorder records are present. A module for product disaggregation is needed. 

Concerning the details of a component to handle product disaggregation: You 
should use the Knapsack or Hax-meal disaggregation scheme in allocating planned product type 
procurement amounts to family and non-family item members of product types. These schemes 
work best for situations with setup and holding costs such as yours. The estimated family and 
non-family item ordering cost of the purchasing department is 72. 

The average family and non-family item ordering cost of the purchasing 
department is 12. The computed ordering cost for multi-item orders of the purchasing 
department is 72. The item ordering cost of the purchasing department is between two and 5 
dollars. The average item ordering cost of the purchasing department is 4. The number of the 
items per order of the purchasing department is between 11 and 25. A component to handle 
lead time determination in the purchasing department is needed. Concerning the details of a 
component to handle lead time determination: A safety lead time should be added to your best 
current estimate of the procurement lead time when order amounts are to be determined. 
Emergency lead times should be used only when items are unexpectedly stocked out. You 
decided that the items with variable lead times of the purchasing department ere important. 

The percentage of items with variable lead times of the purchasing department is 
15. Lead time dependencies are absent. Vendor lead time dependencies in the purchasing 
department are absent. Seasonal lead time dependencies are absent in the purchasing 
department. Order size lead time dependencies are absent. Multi-vendor items are present. 
Vendor price tradeoffs are absent. Lead-time records are present. Vendor tradeoffs are 
absent. A component to handle vendor selection in the purchasing department is unnecessary. 
A routine for computing eoq's is possible. Concerning the details of a routine for computing 
eoq's: The standard economic order quantity formula should be used for most of your items. A 
formula that takes quantity discounts into consideration should be used in determining the order 
quantities of items and families that have certain economies of scale in ordering from vendors. 

The estimated item holding-cost of the purchasing department is 0.92. The 
purchase cost item of the purchasing department is between two and 5 dollars. The variable 
item holding cost of the purchasing department is between 20 and 25 percent. 

Items with non-instantaneous replenishment rates are absent. It is not known 
whether extremely-expensive items in the purchasing department are present. 

A decision concerning the necessity of a routine for determining order quantities of 
extremely expensive items could not be made. A module for the forecasting of seasonal items 
in the purchasing department is possible. A component to handle the forecasting of seasonal 
items is needed. Records of seasonal factors are absent. A module for the forecasting of 
limited-sales-season items is needed. Limited-sales-season items »ra present in the purchasing 
department. You decided that the limited-sales-season items of the purchasing department are 
important. The percentage of limited-sales-season items of the purchasing department is 10. 
The limited-sales season item overage cost of the purchasing department is the cost to liquidate 
and the off-season holding cost. Slow-moving items are present. You decided that the slow- 
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moving item* of the purchasing department are important. The percentage of alow-moving 
item* of the purchasing department is not Known. Concerning the details of a rooduta for the 
forecasting of «towmoving items: The fore««*«n|^f demand lor done by 

expc^wntist smoothing with • very «ms« smoothing factor. A 

forecasting of slow-moving items in the purchasing department is rieeoed. A component to 
handle the forecasting of slow-moving Herns is possible. Item* with e/rette demand ere accent 
in the purchase department A module for the f o rec o rtfrt fc ; « nd Is 

unnecessary. A com po n e nt torwtdm the fore^hr^oflte^ wim tfenc% k unnecessary. 

FesNormbie items ere absent. A component to hendle the forecadlng of 
f esMonable iteme m unrttceesery* ft » not Kriown whether p1«l sresdnt. 

A decision concerning the necessity of » component to heridte tJsj forecasting of 
promoted items could not be mads. It I* not Known whether eeVertisetJ Items Iff trifputtheeing 
department ere present. 

A decision concerning the necessity of a module ferine forecasting of advertised 
items in the purchasing depot l i uofit could not be made. A moduli to support the prodtctJen of 
item life patterns is unnecessary. 

Items thai experience large order* ere present. Ydo decided that the control of 
items that experience Jorge orders of the purchasing de| A modulo to 

filter targe orders is unn eos s s sr yv 

Emerf*r^lee*tlii^aNpr^^ 
price-increases ere present in the purchasing dspertmsnt. Emerfency lead-time quentlty- 
restrictiom are present. Ybu decMedt safety laotf / t i m e * ore e|§retfr|itt>.. 

e ta t ^ i »* i » . ! WMtJ f t i ei».'* » »'»s a , » » jstJ i iaftpe. 4r*o, sv»e k t 1 *. s.<{'»*».jHj | l* ) i» y o ■»'» «' a; »»» » t!,ir « er t j! ereron i n s; 

A mm m t ry of t teU m tl oim mi* by PROCTOR. 

Date of sesslont April 27, 1976 
Time session started: 8«D3 pm 

User's nemo: Mr. Adam Smith 

The following data is shout the purchasing department. 

A component to handle joint ordering constraints is nsedsd. The reeson for the 
decision is thet you decided that the ftMt brderfnjf constraints of th« pu>cha*ing deportment 
ere significsnt. A component to Hindis joM ordering constraint* fa feesiWe. the reesons for 
the decision ere thet 

1 e component to hendle family aggregation is possible. 

2 • module for Je4nt ordering « ■weded 

3 the averige number Of ft* famffy item* of %i purehjM department is more than 20. 

Concerning the details of s component to handle joint or dering constraints; Items 
thet exporieneo Joint-ordering interactions smMhat share common inventory cherecteristics 
should be aggregated into temiHes. Thereasens for thededtft 

I e cwnponsfrt to hendfe %m erdK^l^fwtratntt 4 ^ the ig department is 
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2 joint ordering constraints are present. 

A module for family aggregation in the purchasing department is possible. The reason for the 
decision is that you decided that the family aggregation of the purchasing department is 
possible. A component to handle family aggregation is needed. This is because a module for 
joint ordering constraints is feasible. Concerning the details of a component to handle family 
aggregation: Items that experience joint-ordering interactions and that are aggregated into 
families because they share common inventory characteristics, should be ordered together to 
achieve benefits of economies of scale. This is because Joint ordering constraints are present 
and a component to handle joint ordering constraints in the purchasing department is feasible. 
A module for family disaggregation is needed. This is because a module for family aggregation 
in the purchasing department is needed and A component to handle joint ordering constraints is 
feasible. Concerning the details of a module for family disaggregation: Procurement amounts 
that are allocated to families should be allocated to family members so that items in families run 
out simultaneously. This is because a module for family disaggregation is needed and a module 
for joint ordering constraints is feasible. A procurement aggregate planning module is needed. 
This is because you decided that the external constraints of the purchasing department are 
Important. A procurement aggregate planning module is feasible. The reasons for the decision 
are that 

1 the average number of the variables of the aggregate purchasing plan of the 
purchasing department is not more than 1500. 

2 the average number of the constraints of the aggregate purchasing plan of the 
purchasing department is not more than 1000. 

3 a component to handle middle-range forecasting is possible. 

4 a procurement aggregate planning module is needed. 

Concerning the details of a procurement aggregate planning module: Procurement amounts for 
product types, non-product families and non-product non-family items that are subject to 
external constraints should be determined by means of a linear programming model. This model 
should optimize holding and storage costs while obeying external constraints. This is because a 
procurement aggregate planning module is feasible and external constraints are present. A 
module for product aggregation is needed. The reason for the decision is that a procurement 
aggregate planning module is feasible. Concerning the details of a module for product 
aggregation in the purchasing department: Items and families that share common inventory 
characteristics and demand patterns and that are subject to external constraints should be 
aggregated into product types for purposes of aggregate planning. The reasons for the 
decision are that 

1 external constraints are present in the purchasing department. 

2 a procurement aggregate planning module is feasible. 

A module for middle-range forecasting is possible. The reasons for the decision are that 

1 the data for forecasting of the purchasing department is available. 

2 the average length of the data for forecasting of the purchasing department is not less 
than one year. 

A module for middle-range forecasting in the purchasing department is needed. The reason for 
the decision is that a procurement aggregate planning module is needed. Concerning the details 
of a module for middle-range forecasting in the purchasing department: The demand for product 
types, non-type families and non-family non-type items should be forecast by exponential 
smoothing. These forecasts may be disaggregated according to the relative annual demands of 
members. Demand for slow movers can be forecast by exponential smoothing with a small alpha. 
The reasons for the decision are that 

1 a module for the forecasting of seasonal items is needed and a module for the 
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formatting of seasonal items it possible. 

2 a component to hand* the forecasting of stew-moving items it needed and a 
compOfienttofiar^ffieforecerlJrarof i 

3 « procurement egtrsgete pfares^mlsirtMs featfbki or • module for jotnt ordering 
conetrelnt* 4e feasible. 

The data for forecasting of the purchating department ft available. Sin u have 
records Of sale* and b a c h o rds rt thai err*rror I ff should be possible 1 to recreate a good, 
estimate of your dawand peNernt. TfiU it betsuse sites rtcordt>rf pritinf In fhe *urchesfn§ 
depertmera and becttortmr rswrds are present ftaferrorl efi^l trtfa mbd1u% fdr Middfe- 
rweje forecasting is needed snathe Wglhtf the silie : i*cdrdt of *He p^crwslng deportment ie 
not Hm then one year. A3eetsi»ri~cer#r4nf m hie W *% 

deterwOnat^ coOWnot be mad* The reason for the dacn it tNiflr it oof lo^otVn wterther 
leisj ls^tfnWHWIm¥erV^ 

A decision concarn tn g tha type of a module for long toad t|mo determination in tho 
purchasing department couM not be made. TMt it beeeusa Ft it no* known whether Ibng lead 
time 4tefwt^re W «» W^ ^ wwMb*^ tt oeeiute a . ' :■ 

component to handle product aggregation in the purchating department it needed end a 
procuremenf'tf^egtleplenntng me*ie is fsatibm. ^ffmmgi ebewonant to 

handle product diteggregation in the purchasing osperhjwnt: You ti use th#fSMpa|)cl( or 
Hax-meel dttefgregetlew tthei^ 1n tlWeaBni f> 

family and non-family item members of product typ^i. TrSst i«n| feet fef sTtuetione 
with setup and holding cottt si yours; the roaaori f# the dlM^ are that 

1 a module for product diso agra^WS rf It needed. : ' ' ^ ' '' 

2 the estimated family end non-family item ordering cost of the purchating department ie 
more than two deflart. ■ 

3 a prc ^u wmen t eggregete planning mo<Me It fettfele. 

A component td'ihendfe feed time determination \* headed, this l« because you decided that the 
items with votfeblVlesd ftmet of the purchasing d »h mutant Obnettrnbtg.t^e 

detettt Oil e module for wed tfm* determination: A feed time mp&jm, addtd to yjbur. boat 

current estimate of the procurement 1 teed time whelf order amount* are toW olforinineot 
Emergency teed times should be usedonly when Items ere u ne yp ect ed ry stocked out. The 
reason* for thfc decMfcrta+e that 

1 Omergency l ai d tim e s are present in th% pbrcftas^ 

2 restrictions are present. 

3 You decided that the safety tead4fmes of the purchasing department »• appropriate. 

A component to handle vendor selection is unnecessary. This is because vendor tradeoffs are 
absent. 

A routine for computing eoq's it possible. This Is because a module for midde- 
range forecasting is possible and the estimated family and non-family item ordering cost of the 
purchasing department is not less than two dollars and the estimated family and non-family '*•*>■■. 
ordering cosr of the purchasing deportment divided iy the esfi t uaf e d item bc4dJrtg-<©«t ot the 
purchasing department is Metres then9.CS, CbncerW computing 

eoo/»( The «tewderd%©or«o*t*erder quanffty formula st osedWmostOf your m. A 

formula thai tehee economies of scale into contideretten should be used in determining tfts) 
order quantities ot items end f emMs* that have certain econ bi Mtot df scale in ordering from 
vendors. The reiwc^ for the decision era that j 

1 e routine for computing eoq's is possible. 

2 a component to h an ds * j o i nt ord ering constraints it feasible. 
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A decision concerning the necessity of a routine for determining order quantities of extremely 
expensive items could not be made. This is because it is not Known whether extremely- 
expensive items are present. A module for the forecasting of seasonal items is possible. The 
reasons for the decision are that 

1 the data for forecasting of the purchasing department is available. 

2 the average length of the data for forecasting of the purchasing department is not less 
than one year. 

A module for the forecasting of seasonal items in the purchasing department is needed. This is 
because seasonal items are present in the purchasing department. A module for the forecasting 
of limited-sales-season items in the purchasing department is needed. The reason for the 
decision is that you decided that the limited-sales-season items of the purchasing department 
ere important. Concerning the details of a module for the forecasting of slow-moving items: 
The forecasting of demand for slow movers can be done by exponential smoothing with a very 
small smoothing factor. This is because a component to handle the forecasting of slow-moving 
items in the purchasing department is needed and a component to handle the forecasting of 
slow-moving items is possible. A module for the forecasting of slow-moving items in the 
purchasing department is needed. This is because you decided that the slow-moving items of 
the purchasing department are important. A component to handle the forecasting of slow- 
moving items in the purchasing department is possible. This is because the data for forecasting 
of the purchasing department is available. A component to handle the forecasting of items with 
erratic demand is unnecessary. This is because items with erratic demand ere absent in the 
purchasing department. A module for the forecasting of items with trends is unnecessary. This 
is because items with trends are absent in the purchasing department. A component to handle 
the forecasting of fashionable items is unnecessary. This is because fashionable items ere 
absent. A decision concerning the necessity of a component to handle the forecasting of 
promoted items could not be made. This is because it is not Known whether promoted items are 
present. 

A decision concerning the necessity of a component to handle the forecasting of 
advertised items could not be made. This is because it is not Known whether advertised items 
are present. A module to support the prediction of item life patterns is unnecessary. This is 
because you decided that the support of prediction item-life is unimportant A module to filter 
large orders is unnecessary. The reason for the decision is that you decided that the control of 
items that experience large orders of the purchasing department is unimportant. The current 
question numbers range from 1 to 76. Now the following is a list of possible summaries of 
responses to questions. 

A summary of retpontes tntered by Mr. Smith. 
Reese select one of the following: 

1 print a summary of all questions 

2 print selected questions 

3 return to toplevel 

(Enter here): I 
Question one 
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concerns the name of KBS Foods Ltd 
ra«ponsa: KBS Foods Ltd 

Question two 

concorns the address of KM Foods Ltd 
response: Cambridge MA 02r4S 

Question 3 

concerns whether the activity of KBS Foods Ltd is purchasing 
response; yes '" 

Question 4 

concerns tha number of the purchasing departments Of KBS 
Foods Ltd 

teaponeet 1 

Question5 

concerns whether there are many items of the p urch a sing department 
response: yes ■ 

Question 6 

concerns the status of ec ono mie s of tronsportstion 
responses absent 

Question 7 

concerns the status of common ordsring costs 
rsapeweer «»Bt Known 

Question 8 

concerns tha status of complex orders 
response: absent ' : 

Question 9 

concerns the status of muttHtem orders 
response: present 

Question 10 

concerns the status of joint quantity discounts in tha purchasing department 
response: not Known 

Question It 

concerns your judgement concerning the possibility of thej femtiy aggregation of the 
purchasing department 
response: possible 

Question 12 

concerns the percentage of non-family items of the purchasing department 
response: 30 

Question 13 

concerns your judgement concerning the significance of joint ordering constraints of the 
purchasing department 
response: significant 
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Question 14 

concerns the number of tha items of tha purchasing department 
response: between 8001 snd 10000 

Question IB 

concerns the number of the families of tha purchasing department 
rMponso: between 101 end 250 

Question 16 

concerns your dasire to the family aggregation of tht purchasing department 
response: not-desired 

Question 17 

concern* the status of storage constraints 
response: absent 

Question 18 

concerns tha states of financial constraints 
■* response: aoient ' ,,^l,. . '.,,"" 

Question 19 

concerns the status of vendor contrscts in the purchasing department 
response: absent, . . : -... . ■ . ■ . - 

Question 20 

concerns the status of vendor supply-limits in the purchasing department 
response: present 

Question 21 

concerns the status of seasonal-inventories in tha purchasing department 
response: present 

Question 22 

concerns your judgement concerning tha importance of external constraints of the 
purchasing department 
response: important 

Question 23 

concerns the percentsge of aggregateJy-pjamad items of the purchasing department 
response: 65 

Question 24 

concerns your judgement concerning tha possibility oi the product aggregation of the 
purchasing department 
response: possible 

Question 25 

concerns the number of the product types of tha purchasing department 
response: between 21 and 50 

Question 26 

concerns the ststus of a aggregate purchasing plan 
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response: absent 

Question 27 

concerns the length of the horizon of the ^gregsts purchasing plan of the purchasing 

deportment 

response: between 6 and 12 months 

Question 28 

concerns your desire to assume tha length of the horizon of the aggregate purchasing 
plan of the purchasing department 
responses tfesired 

Question 29 

concerns the time period division of tha aggregate purchasing plan of the purchasing 
department * 

response: one month 

Question 30 

concerns your desire to assume tha tima period drvfcton of tha aggregata purchasing plan 
of the purchasing department 
response: desired 

Question 31 

concerns your desire to the product aggragatton of tha purchasing department 
response: not-desired 

Question 32 

concerns the status of items with trends 
response: absent 

Question 33 

concerns the status of seasonal items 
response: present 

Question 34 

concerns tha status of demand records in the purchasing department 
response: absent 

Question 35 

concern* the status of long lead time items In tha purchasing department 
response: not known 

Question 36 

concern* the status of imported items 
response: absent 

Question 37 

concerns th* status of sales records 
response: present 

Question 38 

concerns the status of backorder racords 
response: present 
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Quottion 39 

concern* tho ttttut of orrort 
rotponto: obtont 

Quottion 40 

concornt tho longth of tho torn* rocordt of tht purchttkw, doportmont 
■ rotponto: moro thtn 3 yoort 

Quottion 41 

concornt tho ptrlodklty of tho towt rocordt of tho purcfcatttw, doportmont 
rotponto: by-month 

Quootion 42 

concornt tho item ordoring cott of tho purchoting doportmont 
rotponto: b t tw w rr two twdg do*** ■■•■■ - 1 " 

Quottion 43 

concornt tho numbor of tho itomt por ordor of tho purchotJng doportmont 
rotponto: botwoon 11 and 26 , ^ 

Quottion 44 

concornt tho dogroo of variability of tht load-tJmot of tht purchotin* doportmont 
rotpomo: fairly variable " 

Quottion 45 

fr y?, V™ Judgomont c oiKorntag tht importoneo of itomt with ver iablo >«»d t imo. of 
»no purcnoatng ooporfmont 
rotponto: important 

Quottion 46 

concornt tho porcontogo of itomt with varlbtto mod «mot of tho purcbtirw. doportmont 
rotponto: 15 

Quottion 47 

concornt tho ttaharof ordtr aixowad ttma dtpandancmi 
rotponto: obtont 

Quottion 48 

concornt tho ttttut of tootonol mod timt dtpondtncmi 
rotponto: obtont «• ^ 

Quottion 49 

concornt tho statu* of mutti-vondor itomt 
rt 



Quottion 50 

concornt tho ttttut of wtd-timo rocordt in tht purchoting doportmont 
rotponto: protont * * v - 

Quottion 51 

concornt tht purchoto cott itom of tht purchoting doportmont 
rotponto: botwoon two •** 5 ooMro -vt.^v ..?■■■.■*» 
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QuMtion52 

concerns the status of vendor load tints dependencies 
rosponso: absont 

Question 53 

concerns the *tatus of vendor price tradeoffs 
rasponse: absent 

Question 54 

concerns the variable item holding cost of the purchasing department 
response: between 20 and 29 percent 

Question 55 

concerns the status of items with non-instantsnaow rsptiniihmant rates 
responsei absent 

Question 56 

concerns the statu* of extremely-expensive items 
response: not known 

Question 57 

concerns the status of records of seasonal factors 
response: absent 

Question 58 

concenwthe number of ths typ»« of s«moimI itsins of tha pircnasing oapartment 
response: more than 5 

Question 59 

concerna the status of limited-seta-season items 

rlimpibM^lgtftliint '* ' 

Question 60 

concerns your judgement concerning the importance of limi ted s a le s s e aso n iteeia of the 
purchasing department » 

response: important 

Question 61 

concerns the limited-sales season Item overage cost of ths purchasing department 
response: the cost to liquidate and the off -season hoMngeoat 

Question 62 

concerns the r»ircentege of limltad-tstes-sasson items of the p u r chasing d e p ot t moii t 
response: 10 

Question 63 

concarns the status of slow-moving items 
response: present 

?- < 
Question 64 

concerns your judgement concerning the importer** rf slow-moving Hems of the 
purchasing department 
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response: important 



Question 65 

concerns the percentag • of slow-moving items of thtptrcheaing department 
response: not known 

Question 66 

concorns the status of items with erratic demand 
response: absent 

Question 67 

concerns the status of fashionable items 
response: absent 

Question 68 

concerns the status of promoted items 
response: not known 

Question 69 

concerns the status of advertised items 
response: not known 

Question 70 

concerns your judgement concerning the Importance of support of prediction item-Jife 
response: unimportant 

Question 71 

concerns the status of items that experience large orders 
response: present 

Question 72 

concerns your judgement concerning the importance of control of items that experience 
large orders of the purchasing department 
response: unimportant 

Question 73 

concerns the status of emergency lead-times 
response: present 

Question 74 

concerns your judgement concerning the appropriateness of the safety lead-times of the 
purchasing department 
response: appropriate 

Question 75 

concerns the status of emergency lead-time quantity-restrictions 
response: present 

Question 76 

concerns the status of emergency lead-time price-increases 
response: present 

The following is a list of possible summaries of responses to questions. 
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Please select on* of the follow i ng : 

1 print a ew**^ of *o*eettem ' - 

2 print s ele c te d qoaettons 

3 return to toplevet 

(Enter here): ! V s , 

Mr. Smite /••Jj <*et A* Am dens mas** /«r MAy. (Tm awtae tseft sees* m Asa**/ 



And Mr. Smith, you ore at top level Wow select ont of tho fo H owt ng: 

lquit 

2 continue tho analytic 

3 help 

4 chenge answers 

5 summarise tho analysis 

(Enter her*): 1. 

Now do you reatiy want to quit? 
(Please key In ye* *Tf»):Y. • 

Do you wish to sav* what you have dona so far? 
(Please Key in yes or n©)» y, 

A record of this session wHI be saved Mr. Smith, do want a MsHng of the session submitted for 

printing? 

(Please key in yes or noh n 



CS-TR Scanning Project 

Document Control Form Date J^/J_L_/_LL 

Report # Lc5-Tfe- U° 

Each of the following should be identified by a checkmark: 
Originating Department: 

□ Artificial Intellegence Laboratory (Al) 
^ Laboratory for Computer Science (LCS) 

Document Type: 
^ Technical Report (TR) D Technical Memo (TM) 

□ Other: 

Document Information Number of pages: nofa-r/t*^ 

Not to include DOD forms, printer instructions, etc... original pages only. 

Originals are: Intended to be printed as : 

□ Single-sided or □ Single-sided or 

X Double-sided P^- Double-sided 

Print type: . 

□ Typewriter pis Offset Press □ LaserPrint 

□ InkJet Printer □ Unknown □ Other: 



Check each if included with document: 

f^ DOD Form ( £ } □ Funding Agent Form □ Cover Page 

□ Spine □ Printers Notes □ Photo negatives 

□ Other: . 

Page Data: 

Blank Pageso*,-*. «**«): 



Photographs/Tonal Material (wwunW- 



Other (notodMcription/paganumtMi): 

Description : Page Number. 

Ac k/vo uLsnC* rrwuTS TARLF5 o f cj /vTp-> 



Scanning Agent Signoff: _ 

Date Received: /3-V » i / ^S Date Scanned: / / '*7 T£ Date Returned: I I ** I JL 



%^kA fa r^k 



Scanning Agent Signature: gv\K&r*dJ\ — \ y v {<<7\n\ , r«v»w ds/lcs Doom** control Fom tat**™ wd 



SECURITY CLASSIFICATION OF THIS PAGE (Whmn Dmtm Entered) 



REPORT DOCUMENTATION PAGE 



i. reporT DUMBER 

Technical Report 160 



READ INSTRUCTIONS 
BEFORE COMPLETING FORM 



2. GOVT ACCESSION NO 



S. RECIPIENT'S CATALOG NUMBER 



4. TITLE (and Subtitle) 

A Program for the Design of 
Procurement Systems 



5. TYPE OF REPORT & P£RIOO COVERED 

S.M. Thesis, May 7,1976 



1. AuthArM 

Michael Bosyj 



«. PERFORMING ORG. REPORT NUMBER 

Technical Report 160 



B. CONTRACT OR GRANT NUMiERfl) 

N00014-75-C-0661 



TfBTCRWNTrSRo'ANIZATlON NAME AND ADDRESS 

Massachusetts Institute of Technoloqy 

Laboratory for Computer Science 

545 Technology Square 

Cambridge, Massachusetts 02139 



W program Element, project, task 

APCA * WORK UNIT NUMBERS 



4 1. CONTROLLING OFFICE NAttE ANO ADDRESS 

Advanced Research Projects Agency 



to r M nt °- D ^ fense 



son Boulevard 



U. REPORT DATE 

May 1976 



ftsi)^6r>arjmtiij^ 1 Ait\ mm 



13. NUMBER OF PAGES 
169 



Office of Naval Research 
Department of the Navy 
Information Systems Program 
Arlington, Virginia 22217 



^tTdWSrmnt /rem Controlling Office) 



tS. SECURITY CLASS, (ot thle report) 

Unclassified 



15*. DECL ASSIFICATION/DOWNGRADtNC 
SCHEDULE 



W"T1TrffIBuTToTT?TTTTMTNT7eT?Rn^!po?fr 



Approved for public release; distribution unlimited 



17. DISTRIBUTION STATEMENT (ot too mbmtrmct entered In Slock 20, II different from Report) 



18. SUPPLEMENTARY NOTES 



19. KEY WORDS (Continue on revere* aide II neeeeemry and Identity by block number) 



Interactive Questionnaires 

Applications Customizers 

Hierarchical Planning and Control Systems for Procurement 

Knowledge-based Systems 



20- ABSTRACT(ContinuoanrovereoaHlolinecoaam 

Computer technology has had limited success in - 
producing useful business applications* Management systems 
seldom meet users' requirements, are often inappropriate to 
an application, and are frequently abandoned. But why? 

Business lacks expertise in the application of 
computers. Managers who are exper t in solving business (cont'd) 
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20. problems find it difficult to specify formal procedures for 
the solution of these problems. It is not surprising that 
programmers who work from poorly defined specifications produce 
poorly written software. The computer industry has provided only 
limited support in business applications. Application packages 
are seldom appropriate to a problem and are often misapplied. 
Misapplication is the principle reason for their failure in 
practical situations. 

improvements are certainly, possible. The manager could 
be supplied with a system that assists in the design of an 
application. This system could help the manager specify his 
requirements by providing him with a framework for thinking 
about issues relevant to the design of a particular application. 
The manager might then be better equipped to select a commercial 
package or- to guide in the design of his own implementation. 

This thesis describes a prototype version of such a 
system. PROCTOR is a program that assists in the design of a 
hierarchical planning and control system for a procurement firm. 

PROCTOR is implemented as an "unstructured" ; e^ _- ._ 
questionnaire. It guides the user in investigating various 
aspects of a problem while giving him complete freedom in 
deciding how and when to supply answers to questions. It allows 
him to change and skip answers whenever he desires. PROCTOR is 
implemented in OWL, a system for representing and processing 
conceptual knowledge, it uses the OWL data base to represent 
procedures for the questionnaire and to store data accumulated 
during the interaction. This representation makes possible the 
presentation of an English-like problem description, various 
evaluations and the reasons for the evaluations. 
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